TMC stürzt ab

Super vielen dank, werde es gleich mal ausprobieren.

Gruß Jojo

Hallo Jojo,

Zitat

Original von JojoK
Kann Stefans Programm denn auch in einer Schleife alle 25 Minuten den Hotkey senden?

Momentan beendet sich mein Programm nach jeder Aktion sofort wieder.
Um eine Timerfunktion zu realisieren, müsste ich eine "Server-"Instanz permanent im Hintergrund laufen lassen.
Möglich ist alles und wenn gewünscht, dann kommt es auf die ToDo-Liste!

Gruß,
Stefan

Das ist unbedingt erwünscht, Stefan!
Ich liiiiiebe Dein Tool!

gruss sokobana

EDIT: Erledigt.

Zitat

Original von StefanDausR
Möglich ist alles und wenn gewünscht, dann kommt es auf die ToDo-Liste!

Hallo Stefan,
das wäre toll! Wieviel Speicher würde das denn permanent kosten? Ich nehme mal an, nicht viel, oder? Gruß, wind-hund

Hallo wind-hund,

Zitat

Original von wind-hund
Wieviel Speicher würde das denn permanent kosten?

das kommt darauf an, was das Programm im Hintergrund dann so alles machen soll...
Es ist ja nicht nur der Arbeitsspeicher! Viel begrenzter sind oft die Systemressourcen. Man kann z.B. nicht beliebig viele timer gleichzeitig anfordern.
Aber ich denke, das kann man schon recht "schlank" hinbekommen!

Gruß,
Stefan

Zitat

Original von StefanDausR
Hallo Jojo,

Momentan beendet sich mein Programm nach jeder Aktion sofort wieder.

Und das ist ja gerade das schöne!

Zitat

Original von StefanDausR
Um eine Timerfunktion zu realisieren, müsste ich eine "Server-"Instanz permanent im Hintergrund laufen lassen.
Möglich ist alles und wenn gewünscht, dann kommt es auf die ToDo-Liste!

Auch wenn das Tool immer mehr zum "Schweizer-Messer für Medion-PNA" wird, bin ich der Meinung, dass die Timerfunktion da nicht rein sollte.
Da wäre doch vielleicht eher ein separates Programm angebracht. Dieses Programm kann ja dann zeitgesteuert alles mögliche (koord456 oder andere Programme) starten bzw. Befehle ausführen.
Die Zeitsteuerung ist ja sicherlich nicht das Problem, aber man muss Vorkehrungen treffen, wie man dieses auch überwacht (welche Timer z.B. gerade laufen). Somit bräuchte man wohl eine GUI dafür und/oder Mechanismen, die versehentliche Mehrfachaufrufe verhindern.

Wobei sich hier für mich sowieso die Frage stellt, ob es nicht sinnvoll wäre, koord465 in mehrere kleine Tools zu zerlegen - zumindest, wenn noch mehr dazu kommt.
Es ist ja derzeit:
- Koordinaten- und Routingprogramm-Ergänzung
- Tunnelverbieter und Helligkeitssteuerer
- Maus- und Tastaturklick-Simulator
- Registry-Patcher
- Dateikopierer, Taskbarmanipulator, Explorerstarter, Fenstersteuerer
(habe ich noch was vergessen?)

Es wird bei jeder kleinen Funktion, die man benötigt, das ganze Programm geladen und gestartet (ver 1.01 = 9 kB, ver1.08r1 = 39 kB) wobei es meist so ist, dass die Programme im Ram deutlich mehr verbrauchen.
Und es ist jetzt schon sehr schwer, die Parameter im Griff zu behalten - zumindest, wenn man nicht sehr viel oder sehr häufig damit rumexperimentiert.

Ich hoffe, dass da noch einiges an Ideen und Umsetzungen kommt - ohne koord465 würde mir einiges fehlen bei meinem Navi!
Das Programm sollte allerdings m.E. bei seiner arbeitsweise bleiben, einen Befehl auszuführen und sich zu beenden und nicht (die Möglichkeit haben) im Hintergrund laufen (zu können).

Gruß,
Martin

Hallo Martin,

ich kann deine Bedenken schon nachvollziehen und die Idee mit der Aufteilung wurde auch schon mehrfach angedacht, aber:

1) Mehrere Einzel-Programme sind schwieriger zu warten (mehrere Source-Cordes mit ähnlichem Inhalt).

2) Für dem Anwender (Skinner) ist es auch nicht gerade einfach, wenn er z.B. 5 Programme updaten muss.

3) Das Parameter-Problem bleibt aber auch bestehen, wenn man mehrere Programme daraus macht. Da hilft nur eine bessete Duku (Ich arbeite daran...)

4) Den größten Teil der Programmgröße machen die Fenster aus (Routenfenster, Koordinatenfenster kleine Auflösung und Koordinatenfenster große Auflösung) außerdem wird Speicherplatz für etliche String-Konstanten reserviert. Die Programmgröße sagt aber nicht unbedingt etwas über die Ladegeschwindigkeit und Arbeitsspeicherbelegung aus.

5) Falls ich einen "Server-Modus" einbaue, dann sicher auch über Parabeter, do dass die jetzige Programmfunktion beibehalten wird.

6) Das Instanzen-Problem kann man dabei schon gut in den Griff bekommen! Es ist auch bereits jetzt schon so, dass -sobald ein Fenster geöffnet wird- keine zweite Instanz (mit Fenster) mehr geladen werden kann.

So, mal sehen, wie ich weitermache...

Gruß,
Stefan

Moin Stefan,

mein bescheidener Wunsch wäre es, wenn man Koord465 einmal, am besten direkt beim Systemstart über einen Parameter resident laden könnte. Ob das nun "Server-Modus", "Dienst" oder wie in der guten alten DOS-Welt "Terminate & Stay Resident" heisst, ist eigentlich egal.

Jeder weitere Programmaufruf benutzt immer diese residente Instanz des Programms. Das würde eine Menge Ladevorgänge ersparen und wahrscheinlich auch helfen, die bekannten Probleme mit der Speicherverwaltung zu vermeiden.

Just my 2 cents...
BL

Hallo Chris,

was soll ich sagen: ein eindeutiges Jein!

Ein Starten mit dem Parameter tsr= (oder so) würde ich mir auch vorstellen, aber die weiteren Programmaufrufe sind davon unabhängig.
Die "Kommunikation" mit Gopal funktioniert ja mit Programmaufrufen, bei denen Parameter übergeben werden, also muss das Programm erst mal geladen werden und die Parameter müssen ausgewertet werden und dann kann man entscheiden, ob die geladene Instanz genutzt wird oder eine neue benötigt wird.

Wenn ich mir das nun so recht überlege, dann könnte es aber doch auf 2 Programme hinauslaufen:
- Das TSR-Programm so wie jetzt, aber eben resistent
- Ein ganz "schlankes" Programm, das per launch aufgerufen wird, die Parameter auswertet und die entsprechende Funktion im TSR aufruft

Oder gleich die Funktionen in eine DLL auslagern...

Oh je - ich sehe schon, da kommt viel Arbeit auf mich zu und das wird wohl dann eine V2.xx werden.

Gruß,
Stefan

Hallo Stefan,

Du hast natürlich recht, an die Parameterübergabe per Kommandozeile hab ich dabei nicht gedacht. Ob sich der Aufwand lohnt, Funktionen in eine DLL auszulagern, die dann doch erst über ein immer wieder zu startendes Programm aufgerufen werden, ist sicher fraglich - aber vielleicht doch einen Versuch wert?

Ich denke, den Begriff TSR sollten wir hier nicht weiter verwenden, sonst fragt noch einer, was eigentlich DOS ist

Gruß
BL

Was ich schon immer mal fragen wollte: Was ist eigentlich "DOS"?

[OT]

Zitat

Original von sokobana
Was ich schon immer mal fragen wollte: Was ist eigentlich "DOS"?

Wenn ich es richtig in Erinnerung habe war da mal ein mit Fehlern überladenes Programm und ein schlaues Köpfchen hat es gekonnt unter die Leute gebracht, dabei sogar die weniger fehlerhafte Konkurrenz quasi ausgeschaltet.

Vielleicht geht es ja bei Medion so ähnlich, irgendjemand hat nur noch was von den Fehlern in der Erinnerung, und an denen wird jetzt festgehalten, in der Hoffnung bald M$ aufzukaufen?

[/OT]

Hat mal jemand von Euch beim Service nachgehakt, ob das TMC-Problem bekannt ist (und ob daran gearbeitet wird)?

Gruß,
m.g

Hi!
Nachdem ich mich nun durch die Anleitung von Mortscript durchgekämpft habe, bin ich nun zu folgendem Script gekommen (klappt nur mit der neuesten Beta, Link siehe oben, danke m.g.):

While ( true )
Sleep( 1500000 )
ShowWaitCursor
Sleep( 10000 )
if ( WndExists( "GoPal Navigator" ))
Show( "GoPal Navigator" )
SendSpecial( "F9" )
SendSpecial( "F10" )
SendSpecial( "F8" )
Sleep( 10000 )
SendSpecial( "F11" )
EndIF
HideWaitCursor
EndWhile

Dazu musste ich noch in der PFSpecial.skn folgende Zeile erweitern:
GlobalHK: "F6@SettingSC.100,F7@SettingSC.101,F8@MapMenu.leave,F9@RdsTmc.selectPort,F10@SettingSC.10182,F11@SettingSC.10183,HK5@MainMenu.5,HK4@MainMenu.10,SC_OUT@SystemHandling.StorageCardOut"; //byJojo

Der Vorteil:
Es funktioniert mit allen Skins!!! Zudem springen keine nervigen Menüs auf, es wird nur eine Sanduhr 10 Sekunden vorher eingeblendet, da bei der Aktion (alle 25 Minuten) alle Menüs geschlossen werden und man so noch rechtzeitig eine Aktion beenden kann, falls man beispielsweise gerade eine Umfahrung bestätigen will etc.

Zu mindestens schaff ich es dadurch jetzt die Zeit ohne Staumeldungen auf durchschnittlich 2 Stunden zu verlängern, immerhin schon mal ein Anfang...
Allerdings geht dann nach 2 Stunden gar nichts mehr, dann kommt gar nichts mehr rein...

Wenn man dann GoPal ein mal neustartet geht es wieder 2 Stunden. Mir schwebt so vor, GoPal nach knapp 2 Stunden automatisch neustarten zulassen, es muss nur irgendwie dabei überprüft werden, dass nicht gerade in den nächsten 30 Sekunden ein Mannöver ansteht; da will mir bis jetzt noch nichts einfallen, wie man das lösen kann...

Wer eine Idee hat, bitte melden ;D

Gruß Jojo

Bevor ich wieder einmal unsicherer werde kurz meine Erfahrung:

Dank Stefans koord465 fahre ich an einem Tag an die 30 Ziele ab, brauche dazu bis zu 15 Stunden mit Pausen und "Kleinausschaltungen".
Gerade um nicht die Route neu zu justieren und um den Reiserechner und das Tracking zu behalten vermeide ich einen Softreset, mache ihn natürlich vor und nach der "Großreise".

In Sachen TMC und -pro kann ich berichten, immer mal wieder kurz eine leere Liste, meist aber eine ordentlich gefüllte zu haben. In den entscheidenden Momenten war alles "zur Stelle" - von Eifel über Pott, über Wetterau, über Vogtland bis Hohenlohe.

Gerät: PNA470 mit PE2.0 OHNE Patch
Einst.: TMC und pro, automatische Frequenzwahl
Zubehör: VirtComTMC mit POIObserver

Auffällig die Observer-Anzeige "France Inter 105 Meldungen" ohne dass Meldungen in der GoPal-Liste sind (wohl nicht routenrelevant) ?!

Möchte also meinen Stab noch nicht über TMC/pro/GoPal brechen...

Gruß
mobutu