Shellexecute

[Capa]

das hab ich ja versucht aber ein einfaches close oder terminate scheint nicht zu helfen
die project1.exe ist immernoch inuse und kann von der update.exe nicht überschrieben werden.

Delphi-Quellcode:

          try
            ShellExecute(0, nil, PChar(ExtractFilePath(paramstr(0))+'temp\update.exe'), nil, nil, SW_Normal);
          except
            ShowMessage('Update fehlgeschlagen!'+#10+#13+'Konnte Update-Datei nicht finden!');
          end;
          Application.Terminate;

so rufe ich immo die datei auf und beende das programm

[WM_CLOSE]

Hast du es mal außerhalb des Debuggers probiert? Oder hast du evtl keine Schreibrechte(Vista/7)?

Ansonsten könnte es sein, dass ShellExecute das startende Programm als ParentProcess verwendet.
Wenn dem so ist könnte man evtl mit CreateProcess der Sache näher kommen.
Prüfen sollte man das mit dem ProcessExplorer können.

Benutzt du zufällig den Unlocker? Der zeigt namlich das mit dem Handle verknüpfte Programm an.

[Neumann]

Hallo,
solche Sachen kann man mit AutoIt-Scripten gut lösen. Sachen wie Dateien ersetzen,umbenennen, Archive entpacken usw sind mit ein paar Zeilen Code hinzubekommen, wenn nötig auch mit graphischer Benutzeroberfläche.

Habe mir schon einige für mich sehr praktische Tools gebastelt; z.B. ein Fernwartungsprogramm auf VNC Basis (nur neue Oberfläche mit unserem Firmenlogo) Automatisierung für Ressourcen-Compiler, Sicherung von Firebird Datenbanken sowie Rebuild für Firebird-Datenbanken (macht eine Datensicherung, dann Shutdown der Datenbank, nennt die alte Datenbankdatei um und baut die Datenbank aus der Sicherung wieder auf).

Gruß

Ralf

[himitsu]

ShellExecute wird im Falle eines Fehler mit der eventuellen Zieldatei garantiert keine Exception werfen.
Try-Except ist alles komplett fehl am Platz.
> Stattdessen gibt diese Funktion den "Erfolgsbericht" als Result zurück, welches man also auswerten sollte.


Ja, auch ShellExecute könnte eine Exception werfen, aber wenn, dann lag es an einem fehlerhaften Aufruf, wie z.B. einem ungültigen Pointer/String ... also wenn es da doch mal knallt, dann lag es an einem Bediehnungsfehler/Programmierfehler und keiner zu erwartenden Ausnahmebehandlung.
> Try-Except bleibt also falsch und es würde in soeinem Fall die eigentliche Fehlerursache sträflichst verfälschen.

[Capa]

also habs nun mit CreateProcess versucht
im Process Explorer wird die project1.exe unter explorer.exe aufgeführt indem
moment wo er die update.exe startet ist sie erst unter der project1.exe und dann ca 1-2sec
später steht sie ganz alleine da also ohne parent, in dem moment verschwindet auch die project1.exe
ausm PE. Trotzdem tut er es nicht updaten bzw die project1.exe nicht löschen.
Und ja ich teste es ohne Debugger.

Warum tut try except das verfälschen wenn es nur darum geht das die update.exe ihre arbeit nicht machen kann ?


EDIT: mom seh gerade wenn ich auf einstellungen schaue da steht unter Parent die project1.exe doch drin

[WIng2005]

Hallo Capa,

ich hatte mal einen ähnlichen Fall so gelöst:

Eine Starter-Datei prüft, ob Updates vorliegen. Ist dass der Fall, wir die eigentliche Anwendung ausgetauscht und dann erst gestartet.
Der Start meines Programmes erfolgte also stets über eine 2. Datei.

[Capa]

mhh die idee ansich ist nicht schlecht aber ich hab halt in meinem programm das updatefenster
schon eingebaut ^^ bzw soll es halt auch so funktionieren das nach nem update gesucht werden
kann wenn das programm schon läuft.

EDIT: Mir ist da gerade was aufgefallen!
wenn ich die project1.exe starte und dann den updateprocess ausführe spinnt die update.exe rum
weil halt nen parent gesetzt ist.
starte ich aber die update.exe macht der das update und startet dann wieder das programm,
wenn ich dann wieder update mache klappt alles genau so wie es soll.
und solange ich das fenster nicht schliesse klappt das alles und ich kann das so oft durchlaufen
lassen wie ich will.

Warum also nicht wenn ich die project1.exe als erstes starte, liegt das vielleicht daran
das die update.exe ne consolenapplication ist?