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...
. 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...
Entwickler - MeisterGeister-Projekt
Projektleitung
Projektleitung