Too stupid to execute and wait

[QuickAndDirty]

PROBLEM GELÖST

Delphi-Quellcode:

function ExecAndWait(Filename, Params: string; WindowState: word = SW_SHOWNORMAL): boolean;
var
  ShExecInfo: SHELLEXECUTEINFO;
  r : Cardinal;
  const
  SEE_MASK_NOASYNC= $100;
begin
  Result := false;
  if Filename = '' then
    exit;
  if not FileExists(FileName) then
  Begin
    ShowMessage('Datei nicht existent!');
    Exit;
  End;
  ZeroMemory(@ShExecInfo, SizeOf(ShExecInfo));
  ShExecInfo.Wnd := application.MainFormHandle; //GetForegroundWindow;
  ShExecInfo.cbSize := sizeof(SHELLEXECUTEINFOA);
  ShExecInfo.fMask := SEE_MASK_NOCLOSEPROCESS or SEE_MASK_NOASYNC;
  ShExecInfo.lpVerb := 'open';
  ShExecInfo.lpFile := PChar(Filename);
  ShExecInfo.lpParameters := PChar(Params);
  ShExecInfo.lpDirectory := PChar(ExtractFileDir(Filename));
  ShExecInfo.nShow := WindowState;
  Result := ShellExecuteEx(@ShExecInfo);


  try
    if Result then
    begin
      repeat
        R := MsgWaitForMultipleObjects(1, ShExecInfo.hProcess, False, INFINITE,QS_ALLINPUT);
        if r <> WAIT_OBJECT_0 then
          Application.ProcessMessages;
      until r = WAIT_OBJECT_0;
    end
    else
      Showmessage('Fehler beim Starten der Anwendung:' + Filename +
                   #13#10'System Fehler: ' + SysErrorMessage(GetLastError));
  finally
    CloseHandle(ShExecInfo.hProcess);
  end;
end;

WaitForSingleObject produziert scheinbar wie vorgesehen einen deadlock wenn der aufgerufen prozess ein neues Fenster erzeugt.
Und die msdn hatte recht...(seltsam) mit MsgWaitForMultipleObjects geht es dann trotzdem.

Delphi-Quellcode:

      repeat
        R := MsgWaitForMultipleObjects(1, ShExecInfo.hProcess, False, INFINITE,QS_ALLINPUT);
        if r <> WAIT_OBJECT_0 then
          Application.ProcessMessages;
      until r = WAIT_OBJECT_0;

Und danke für die Code Verschönerungstips, sieht jetzt auch viel übersichtlicher aus!

[Luckie]

Zitat von QuickAndDirty:

Und danke für die Code Verschönerungstips, sieht jetzt auch viel übersichtlicher aus!

Und warum nutzt du sie nicht und verhunzt den Code wieder? Wozu dieser komische try-finally-Block? Wo erwartest du da eine Exception? Und du hast ja immer noch diese doofe Fehlerbehandlung da drin.

[QuickAndDirty]

Zitat von Luckie:

Zitat von QuickAndDirty:

Und danke für die Code Verschönerungstips, sieht jetzt auch viel übersichtlicher aus!

Und warum nutzt du sie nicht und verhunzt den Code wieder? Wozu dieser komische try-finally-Block? Wo erwartest du da eine Exception? Und du hast ja immer noch diese doofe Fehlerbehandlung da drin.

habe eigentlich
die von dir empfohlene

SysErrorMessage

funktion benutzt.

sehr praktisch, danke.

Ich packe Handle Freigaben usw. immer in ein Finally. warum magst du das nicht?

wie würdest du es denn machen?

[Luckie]

Delphi-Quellcode:

uses
  ShellAPI;

procedure ExecAndWait(Filename, Params: string; WindowState: word = SW_SHOWNORMAL);
var
  ShExecInfo: SHELLEXECUTEINFO;
  RetValue: DWORD;
const
  SEE_MASK_NOASYNC= $100;
begin
  ZeroMemory(@ShExecInfo, SizeOf(ShExecInfo));
  ShExecInfo.Wnd := Application.Handle ; //GetForegroundWindow;
  ShExecInfo.cbSize := sizeof(SHELLEXECUTEINFO);
  ShExecInfo.fMask := SEE_MASK_NOCLOSEPROCESS or SEE_MASK_NOASYNC;
  ShExecInfo.lpVerb := 'open';
  ShExecInfo.lpFile := PChar(Filename);
  ShExecInfo.lpParameters := PChar(Params);
  ShExecInfo.lpDirectory := PChar(ExtractFileDir(Filename));
  ShExecInfo.nShow := WindowState;
  if ShellExecuteEx(@ShExecInfo) then
  begin
    repeat
      RetValue := MsgWaitForMultipleObjects(1, ShExecInfo.hProcess, False, INFINITE, QS_ALLINPUT);
      if RetValue <> WAIT_OBJECT_0 then
        Application.ProcessMessages;
    until RetValue = WAIT_OBJECT_0;
    CloseHandle(ShExecInfo.hProcess);
  end
  else
    RaiseLastOSError;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  try
    ExecAndWait('C:\Windows\Notepad.exe', '');
    ShowMessage('Fertig');
  except
    on E: Exception do
      ShowMessage(E.Message);
  end;
end;

[samso]

Ich würde vielleicht noch einmal überdenken, ob die verwendeten Flags wirklich zielführend sind. Vielleicht sollte man ja die folgende Kombination verwenden:

SEE_MASK_NOCLOSEPROCESS or SEE_MASK_WAITFORINPUTIDLE or SEE_MASK_NOZONECHECKS

Dann kann man sich vermutlich auch all dieses Application.ProcessMessages-gefrickel sparen.

[himitsu]

Das ProcessMessages sorgt dafür, das der Thread (Hauptthread) nicht "einschläft"

WAITFORINPUTIDLE wartet "nur" bis das gestartete programm "aufnahmebereit" ist, wärend das MsgWaitFor (ohne MsgWaitFor) auf die komplette Beendigung des Programms wartet.

[QuickAndDirty]

Zitat von samso:

Ich würde vielleicht noch einmal überdenken, ob die verwendeten Flags wirklich zielführend sind. Vielleicht sollte man ja die folgende Kombination verwenden:

SEE_MASK_NOCLOSEPROCESS or SEE_MASK_WAITFORINPUTIDLE or SEE_MASK_NOZONECHECKS

Dann kann man sich vermutlich auch all dieses Application.ProcessMessages-gefrickel sparen.

ich habe auch so ein paar sorgen...weil ja aus application.processmessages wieder Excpetions kommen können.... je nach dem was da verarbeitet wird.

Aber wieso erspart mir diese flag kombination das ProcessMessages?

[QuickAndDirty]

Noch ne frage

wo wir gerade am tunen sind...

  ShExecInfo.Wnd := application.MainFormHandle; Oder
  ShExecInfo.Wnd := application.Handle; Oder
  ShExecInfo.Wnd := GetForegroundWindow;

[ChrisE]

Hallo,

da seh ich gerade noch:  ShExecInfo.cbSize := sizeof(SHELLEXECUTEINFOA); Hier sollte das A hinten noch weg.
Und dann noch eine Frage zu dem WaitFor:
Sollte man hier nicht auch auf Application.Terminated prüfen? Ist vielleicht eine Glaubensfrage für den Anwendungsfall aber ich würde es machen. Also etwa so:

Delphi-Quellcode:

repeat
RetValue := MsgWaitForMultipleObjects(1, ShExecInfo.hProcess, False, INFINITE, QS_ALLINPUT);
if RetValue <> WAIT_OBJECT_0 then
  Application.ProcessMessages;
until (RetValue = WAIT_OBJECT_0) or Application.Terminated;

Gruß, Chris

[Luckie]

Zitat von ChrisE:

da seh ich gerade noch:  ShExecInfo.cbSize := sizeof(SHELLEXECUTEINFOA); Hier sollte das A hinten noch weg.

Copy and waste. Ist korrigiert.