[erledigt] Externe Links [#244]

[Acenoid]

Hallo!

ich schäme mich schon fast über so viele Posts bzw. Meldungen hintereinander, aber ich hoffe Ihr freut Euch über das Feedback:

1)
Ich benutze ein externes Programm den aves Routenplaner (tolles Teil übrigens). Wenn ich das Tool "stand-alone" starte geht alles. Setze ich einen Link in "Wege des Wanderers" und starte dann, sind die ganzen Checkboxen, Reiter und Dialoge in dem "aves Routenplaner" unlesbar. D.h. das Programm ist nicht zu benutzen.

2) EDIT Moderation: In eigenen Beitrag verschoben.

[Rondrian]

Punkt 2. habe ich in einen eigenen Thread verschoben (s.o.).

Zu 1): Kannst du vielleicht mal einen Link zu diesem Tool posten? Ich konnte es grad nicht auf die schnell finden... Ich kann das Problem nicht ganz nachvollziehen, da der Link nichts anderes macht, als den von dir eingestellten Link zu dem Programm per Kommandozeilen-Befehl zu starten. Wie startest du das Programm den "stand-alone"? Über eine Verknüpfung? Werden dabei eventuell irgendwelche speziellen Parameter übergeben?

[Marc76]

Ich könnte mich täuschen, vermute aber mal stark, er meint folgendes Tool:

http://www.crystals-dsa-foren.de/showthr...p?tid=2605

[Acenoid]

Genau.

- Das Programm starte ich auch so direkt mit der EXE
- In MG wähle ich "Programm / Datei" und zeige auf die EXE.

Nach kurzem Test würde ich sagen es liegt an dem current Pfad der wohl im MG Hauptverzeichnis verbleibt und nicht in das Tool wechselt:

- MG triggered link im Laufwerk/Pfad <X> (aktuelle dir ist trotzdem noch das MG Hauptverzeichnis).

Als Workaround habe ich nun den Routenplaner in das MG Verzeichnis kopiert und es hat funktioniert.

Also wenn man das Verzeichnis beim Programmstart richtig wechselt, sollte es mit diesem (und vermutlich auch anderen Tools) keine Probleme mehr geben.

[Rondrian]

Super Fehlersuche!
Das hat sehr geholfen.

Wirklich ein interessantes Problem. Das Aves Tool ist da an dieser Stelle aber etwas ungünstig programmiert, wenn das CurrentDirectory genommen wird...

Nun ja, um solche Probleme zu vermeiden, wird nun das CurrentDirectory für den Programm-Aufruf kurzfristig umgestellt und dann funktioniert es auch!

Ich habe das in Ticket #244 behoben und es wird in Version 2.3.4 korrigiert sein.

Danke für die gute Unterstützung bei diesem Problem.

[Hazardy]

Relative Pfadangaben beziehen sich immer auf das Working-Directory und wenn ihr externe Programme mit dem MG-Pfad als WD aufruft, dann könnt ihr das nicht anderen Programmen vorwerfen. Ich vermute MG würde auch nicht wie erwartet funktionieren, wenn man es auf einmal mit einem anderen WD aufruft.

[Rondrian]

Wir starten aber die verlinkten Programme mit einem absoluten Pfad und übergeben nichts an die Programme. Dass das WorkingDirectory nicht das der EXE ist, liegt an dem Standardverhalten des Systemaufrufs.
Wenn ein Programm seine Einstellungen oder sonstige Daten aber im WorkingDirectory sucht, kann man es dem Programm sehr wohl vorwerfen, denn so etwas ist aus meiner Sicht keine besonders gute Idee, da man sich ja nie sicher sein kann, wo das aktuelle Verzeichnis gerade hinzeigt... Man sollte seine Daten immer relativ zur EXE suchen, oder in speziell konfigurierten Verzeichnissen (oder im Standard-User-Verzeichnis oder ähnliches).

Und MeisterGeister hätte überhaupt kein Problem mit einem umgestellten WorkingDirectory, da MeisterGeister seine Daten immer relativ zu sich selbst in seinen Unterverzeichnissen sucht.
Das einzige wo das WorkingDirectory eine Rolle spielt, sind Datei-Auswahl- und Speicher-Dialoge, die das aktuelle Verzeichnis als Vorauswahl verwenden.

Aber wie gesagt, um solchen Problemen aus dem Weg zu gehen, haben wir die beschriebene Lösung umgesetzt, auch wenn dies vermutlich ein extrem selten auftretendes Problem ist... Jedenfalls ist mir das, außer beim Aves-Tool, noch nie bei einem Programm begegnet...

[Hazardy]

Und MeisterGeister hätte überhaupt kein Problem mit einem umgestellten WorkingDirectory, da MeisterGeister seine Daten immer relativ zu sich selbst in seinen Unterverzeichnissen sucht.
Das einzige wo das WorkingDirectory eine Rolle spielt, sind Datei-Auswahl- und Speicher-Dialoge, die das aktuelle Verzeichnis als Vorauswahl verwenden.

Es tut mir wirklich Leid, aber: Nein.
Eine Verknüpfung mit anderem WD angelegt, gestartet, es folgt eine Fehlermeldung, die bei einem normalen Start nicht erfolgt.
Im WD liegt danach eine Log-Datei und ein Ordner "Daten" wird angelegt.
Wenn auch alles andere auf den ersten Blick wie sonst ist, komplett ohne Probleme nimmt auch MG dies nicht hin.

Und ob das nun gutes oder schlechtes Verhalten ist, das ist dann wohl recht subjektiv, wenn ich eine andere Config, Datenbank oder was auch immer ein Programm nimmt in einem anderen Verzeichnis habe, dann bin ich der Meinung es sollte ausreichen das WD zu ändern anstelle die ausführbaren Dateien kopieren zu müssen.

[Rondrian]

Ich habe es gerade mal nachgestellt und ja, du hast Recht, dass der neue AudioPlayer (EDIT: Es ist nicht der neue AudioPlayer, sondern der Start-Jingle) offenbar eine Fehlermeldung erzeugt und unnötigerweise ein leeres Daten-Verzeichnis angelegt wird. Ich nehme diese Sache mal als Ticket auf (#245) und wir werden dieses Verhalten korrigieren. Vielen Dank für's Ausprobieren und den Hinweis . Ich habe meine Aussage dummerweise nicht vorher praktisch überprüft, sondern aus der Kenntnis unseres Quellcodes heraus getätigt . Offenbar haben wir aber an ein oder zwei Stellen das nicht ganz sauber implementiert...

Aber zumindest stürzt MG in diesem Szenario nicht ab und ist weiterhin bedienbar, was im Fall des Ares-Tools nicht so war.

Ich bin nicht der Meinung, dass man den Speicherort für programmrelevante Daten über das Ändern des WorkingDirectory einstellen sollte (kopieren der EXE natürlich auch nicht). Das ist für mich eher eine Art "Hack"-Lösung. Aber gut, das mag eine Geschmacksfrage sein...
Was aber meiner Ansicht nach für jedes beliebige Programm ein zentrales Paradigma sein sollte: Egal was der User (oder ein anderes System) für eine Eingabe macht oder sonstige Umstände erzeugt - das Programm darf nicht (unbehandelt) abstürzen oder unbedienbar werden! Das ist natürlich ein manchmal nicht erfüllbares Ziel, aber man sollte sich bemühen dies im Hinterkopf zu behalten.

Aber ich will hier ja auch nicht das Ares-Tool schlecht reden - darum geht es mir nicht. Es ist nur ungünstig, dass das Tool unter den gegebenen Bedingungen die Bedienung unmöglich macht und keine Meldung ausgibt warum. Hätte Acenoid nicht den richtigen Riecher gehabt, wären wir vielleicht nicht so schnell auf die Ursache gestoßen... Das Ares-Tool hätte es also besser machen können, aber MeisterGeister sicherlich auch. Obwohl ich eigentlich nicht finde, dass es unser Problem ist, wenn wir per System-Befehl ein Programm starten und dieses dann nicht sauber läuft...

[Rondrian]

Ich habe gestern die kleinen unschönen Effekte, die entstehen wenn MG mit einem anderen Arbeitsverzeichnis gestartet wird, beseitigt (#245). Damit sollte meine ursprüngliche Aussage wieder stimmen .
Der Fix wird in der nächsten Version 2.3.4 enthalten sein.