Hallo,

ich hab da schon wieder was merkwürdiges:
Mein Programm verwendet eine INI Datei um sich seine Position zu merken.

Wenn ich das Programm per Doppelklick oder über eine Verknüpfung starte funktioniert alles wie erwartet.

Jetzt starte ich dieses Programm jedoch aus einem anderen heraus über shellexecute.



Dabei wird die bestehende INI Datei ignoriert. Das kapier ich nicht.
Ist das ein Fehler, mein Fehler oder muss das so sein?

naja, vermutlich machst du den Fehler, die ini im Eigenem Verzeichnis und mit absoluten Pfaden zu speichern.
Entweder du übergibst bei shellexecute den Dateipfad mit, oder du schreibst da, wo du die ini öffnest, halt eben nicht

sondern


Das beruht darauf, das bei ersterer Variante das Arbeitsverzeichnis verwendet wird, und bei der 2ten das Programmverzeichnis.
Wenn du mehr infos brauchst:
RELATIVE PFADE

Ähh..
Also hinter myDir verbirgt sich myDir:=ExtractFilePath(Application.ExeName);

Das Problem ist ja auch nicht, die EXE zu starten. Die wird gefunden und geöffnet.
Nur soll sie dann ihre INI lesen und das macht sie grundsätzlich NICHT, wenn sie über die shell gestartet wird.

Ich hab ja keine Ahnung, aber Pfade erscheinen mir da am unverdächtigsten.

Du übergibst an ShellExecute als Arbeitsverzeichnis des Programms nil, dieses ist also vermutlich unsauber programmiert und verwendet keine Pfadangaben für die Ini...
www.delphi-library.d...ewtopic.php?p=499701

Da hat Boldar schon Recht.

jetzt bin ich ganz verwirrt.

Zitat:

dieses ist also vermutlich unsauber programmiert und verwendet keine Pfadangaben für die Ini...

Soll heißen das Programm verwendet keine Pfadangaben für seine INI?
Wie sollte es denn dann seine INI lesen können? Das Programm ermittelt seinen eigenen Wohnort über ExtractFilePath(Application.ExeName) und legt dort auch die INI ab.
Das das nicht so toll ist, wenn man Programme an Andere weitergibt, die vielleicht nicht als Admin angemeldet sind ist mir bekannt, spielt bei diesem aber keine Rolle.



Wenn ich das Programm über eine, auf dem Desktop gelagerte Verknüpfung starte ist ja auch alles gut.
Ich verstehe bis jetzt nicht, warum es einen Unterschied macht, WIE ein Programm gestartet wird.

Ein Programm dass seine INI über eine Pfadangabe findet, findet seine INI über eine Pfadangabe, es sei denn es wird nicht "am Gerät" sondern über die "Fernbedienung" gestartet?
Ich nahm an, dass shellexecute nichts anderes macht als ich, wenn ich auf die Datei doppelklicke. Anscheinend ist das nicht richtig.

Welche Möglichkeit habe ich denn alternativ, um von einem Programm aus ein anderes zu starten?

Der einzige Unterschied ist, dass du kein Arbeitsverzeichnis angibst. Eine Verknüpfung tut das normalerweise. Warum das dann nicht geht wirst du wohl debuggen müssen.

Naja, der Code den du zeigst ist der fürs Speichern der Daten... eventuell hast du dich ja beim Lesen verschrieben und das Pfad ermitteln vergessen... soll ja vorkommen

Ansonsten würde ich auf ein Problem woanders tippen, das nur so aussieht als würde die Ini ignoriert werden.

Ah, also ein Fall für den Computer Freud.
Da hatte das System wohl eine über dominante Mutter und eine schlimme Kindheit.

debuggen bedeutet ich lass mir anzeigen, dass Register $00XY den Wert h009 hat und weiß dann, dass das ja so nie funktionieren kann, richtig?
Ich glaube da lass ich mir lieber eine andere Lösung einfallen. Ich hab mal mit einem 8048(8Bit) Assembler gearbeitet, aber das einzige was ich davon noch weiß ist, dass ich das nie mit einer 80x86 CPU machen möchte. Ich wüsste nicht einmal, wo ich einen Architekturplan für so einen Prozessor herbekommen soll, geschweige denn den Befehlssatz.

Außerdem würde ich wohl nur die genaue Fehler Zusammensetzung erfahren und könnte nichts daran ändern, oder?


Danke für die Unterstützung.

jaenicke hat folgendes geschrieben :

Der einzige Unterschied ist, dass du kein Arbeitsverzeichnis angibst. Eine Verknüpfung tut das normalerweise. Warum das dann nicht geht wirst du wohl debuggen müssen.

Z.B. indem du dir die Variable homedir ausgeben lässt, bevor du sie benutzt (showmessage). Debuggen heißt Fehler finden, nicht mit Assemlblercode rumspielen wenn's nicht grad erforderlich ist
So tief auf Systemebene musst du beim debuggen so gut wie nie gehen, da deine Bugs ja im Delphi-Code stehen und nicht im vom Delphi erzeugten Maschinencode (...da *auch*, ja...).

Debuggen bedeutet, dass du zeilenweise den Programmquelltext laufen lässt und schaust was dabei passiert. Variableninhalte prüfen, ausgeben, etc.

Weil es mich ärgert, hier nochmal:

Wenn ich das Programm mit einem Doppelklick auf die EXE starte findet es die Werte in seiner INI. Das kann ich deutlich sehen und habe es überprüft, in dem ich die Werte in der INI per Hand geändert habe.

Wenn ich das Programm über eine zuvor erzeugte Verknüpfung starte, die sich auf dem Desktop befindet ist auch alles gut.

Nur wenn ich das Programm aus einem anderen Programm heraus starte, und nur dann klappt es mit dem Lesen der INI nicht.

Vorausgesetzt ich habe wirklich keine funktionierende Methode zum Lesen der INI, dann würde das bedeuten, dass in den ersten beiden genannten Fällen allerschwerste Fehler auftauchen, nämlich dass das Programm Daten einliest, obwohl es gar nicht weiß wie das geht.

Gib einfach mal in Delphi (Start --> Parameter) oder der Verknüpfung (Eigenschaften --> Ausführen in) ein anderes Arbeitsverzeichnis an...
Und dann schau ob das immer noch geht, wenn du es aus Delphi oder per Verknüpfung startest...

Yup, ist klar. Auffälligster Unterschied zwischen Verknüpfung und shellexecute: Das Arbeitsverzeichnis, wie schon erwähnt. Darum, schreib doch mal ein showmessage(homedir); vor das ini := TIniFile.Create(homedir + 'asd... und schau ob's wirklich stimmt, was in homedir stehen muss.

Zitat:

Z.B. indem du dir die Variable homedir ausgeben lässt, bevor du sie benutzt (showmessage)

Sowas mache ich bevor ich hier anfrage.

Dann häng das Projekt doch einfach mal an (bzw. kopiere es komplett und lösch vorher den Rest des Quelltextes heraus, wenn du es nicht komplett posten möchtest).

Hallo,

schon mal versucht mit ChDir(); vor shellexecute das Arbeitsverzeichnis zu setzen?

Hmm..

ChDir(); geht schon mal gar nicht; (Es gibt keine überladene Version, die ohne Parameter u.s.w.)

ChDir(ExtractFilePath(Application.ExeName)); führt zu einem IO-Error mit anschließendem Hinweis, das Delphi jetzt kaputt ist und ich am Besten den Rechner neu starte.

Auch erschließt sich mir der Sinn nicht.

ChDir(ExtractFilePath(Application.ExeName));
ini:=TIniFile.Create(ExtractFilePath(Application.ExeName)+myPGM.ini');

Sieht irgendwie doppelt gemoppelt aus, oder?

Also ich habe so ein Bauchgefühl, dass es am Lesen der INI nicht liegen kann, da das ja ansonsten funktioniert.

gizmo hat folgendes geschrieben :

ChDir(ExtractFilePath(Application.ExeName)); ini:=TIniFile.Create(ExtractFilePath(Application.ExeName)+myPGM.ini'); Sieht irgendwie doppelt gemoppelt aus, oder?

Ist auch falsch Du sollst das Arbeitsverzeichniss vor Aufruf von shellexecute durch ChDir ändern.

Per Druck auf F1 bei markierten "ChDir" bekomme ich:

Delphi-Kontexthilfe:

Die Prozedur wechselt das aktuelle Verzeichnis. Unit System Kategorie Dateiverwaltung Delphi-Syntax: procedure ChDir(const S: string); overload; procedure ChDir(P: PChar); overload; C++ Syntax: extern PACKAGE void __fastcall ChDir(const AnsiString S); extern PACKAGE void __fastcall ChDir(char *P); Beschreibung Mit ChDir kann das aktuelle Verzeichnis in den mit S oder P angegebenen Pfad geändert werden. Wenn die Operation fehlschlägt, wird EInOutError ausgelöst. Unter Windows kann der Pfad einen Laufwerksbzeichner enthalten; dadurch wird auch das aktuelle Laufwerk gewechselt. Hinweis: In Delphi können mit dem Compiler-Schalter {$I+} Laufzeitfehler durch Exceptions behandelt werden. Wird {$I-} verwendet, muss explizit mit IOResult auf E/A-Fehler geprüft werden.

Du hast es also eigentlich richtig eingesetzt...

gizmo hat folgendes geschrieben :

Also ich habe so ein Bauchgefühl, dass es am Lesen der INI nicht liegen kann, da das ja ansonsten funktioniert.

Dann lass dir mal die ausgelesenen Werte ausgeben, lass die gelesene ini speichern, indem du noch einen wert reinschreibst, dann schau, ob und wo die ini erstellt/geändert wurde, etc...