Windows 7: Andere Anwendung per ShellExecute starten => error

[Furtbichler]

Hallo,

Ich habe hier (nee, ganz weit weg beim Kunden) ein Problem mit einer Anwendung, das an einer Stelle eine andere Anwendung startet. Das funktioniert unter XP problemlos, aber bei Windows 7 scheint es nicht zu funktionieren. Der Aufruf geht mit dieser Funktion:

Delphi-Quellcode:

Function ShellExecute_AndWait(Operation, FileName, Parameter, Directory: String;
  Show: Word; bWait: Boolean): Longint;
Var
  bOK: Boolean;
  Info: TShellExecuteInfo;

Begin
  FillChar(Info, SizeOf(Info), Chr(0));
  Info.cbSize := SizeOf(Info);
  Info.fMask := SEE_MASK_NOCLOSEPROCESS;
  Info.lpVerb := PChar(Operation);
  Info.lpFile := PChar(FileName);
  Info.lpParameters := PChar(Parameter);
  Info.lpDirectory := PChar(Directory);
  Info.nShow := Show;
  bOK := Boolean(ShellExecuteEx(@Info));
  If bOK Then Begin
    If bWait Then Begin
      While WaitForSingleObject(Info.hProcess, 100) = WAIT_TIMEOUT Do
        Application.ProcessMessages;
      bOK := GetExitCodeProcess(Info.hProcess, DWORD(Result));
    End
    Else
      Result := 0;
  End;
  If Not bOK Then Result := -1;
End;

Problem an der Sache: Ich komme an den Rechner nicht direkt ran, kann also nur per 'Stille Post' Anweisungen geben.


Meine Frage (hier bin ich Laie):
1. Wäre es denkbar, das der aktuelle Benutzer keine Rechte hat, die Fremdanwendung zu starten? Gibt es hier Unterschiede zwischen XP und Win 7?
2. Wenn der angemeldete Nutzer die Anwendung per Doppelklick starten kann, geht das dann auch mit der o.g. Funktion? D.h. reicht es, die Rechte so einzurichten, das Doppelklick funktioniert?
3. Falls 1=JA und 2=JA dann: Wie stellt man das ein?
4. Würde man (1) in einem Windows-Ereignis-Log sehen?


[x] Ja, ich oute mich hiermit als Volldrömel.

[DeddyH]

Zunächst würde ich mal untersuchen, was genau denn eigentlich schiefläuft. Aus der Hilfe zu ShellExecuteEx:

Zitat:

Return value

Type: BOOL

Returns TRUE if successful; otherwise, FALSE. Call GetLastError for extended error information.

Das wäre schon einmal aussagefähiger als ein fest vorgegebenes -1

[Union]

Erhält der Benutzer eine Fehlermeldung? Stimmen die Parameter für Verzeichnis und Dateiname? Handelt es sich um ein Ansi oder Widechar-Delph?

[jaenicke]

Was benutzt du denn als Verb bzw. Operation? Manche geben dort einen Leerstring an, was zwar meistens funktioniert, aber eben nicht immer.
Und ob es an Rechten liegt, kannst du mit dem Verb 'runas' testen.

Aber GetLastError sollte wie schon genannt wurde natürlich am ehesten Aufschluss geben. Sprich z.B. SysErrorMessage(GetLastError) .

Sonst wäre z.B. das Verzeichnis ein Kandidat. Benutzt du sowohl für Arbeitsverzeichnis als auch für die Anwendung selbst einen absoluten Pfad? Denn das Arbeitsverzeichnis mag sich ja ändern, wie dir denke ich klar ist.

[arnof]

Mit welcher Delphiversion arbeitest Du ?

[cookie22]

Was hat das mit der Delphi Version zu tun? ShellExecuteEx ist ein Api Call.

[Union]

Zitat von cookie22:

Was hat das mit der Delphi Version zu tun? ShellExecuteEx ist ein Api Call.

Wegen evtl. Widechar/Ansichar-Probleme.

[jaenicke]

Solange man nicht explizit PAnsiChar oder PWideChar oder ShellExecuteExA oder so benutzt, ist das egal, da es immer funktioniert.

[himitsu]

Zitat von jaenicke:

Solange man nicht explizit PAnsiChar oder PWideChar oder ShellExecuteExA oder so benutzt, ist das egal, da es immer funktioniert.

Aber wenn man es angibt, oder auch nicht, dann muß es dennoch übereinstimmen.
Also PAnsiChar zur ANSI-API, PWideChar zur Unicode-API oder PChar zur dynamischen API.

Und da oben passen die dynamischen String, PChar und API (TShellExecuteInfo, ShellExecuteEx) zusammen.


Sonst endet es, wie in diesem Fall
http://www.delphipraxis.net/32578-ve...ml#post1244905


Auch wenn man da oben hätte ein Else statt dem If Not bOK Then hätte nutzen können
und es vorallem nicht geschadet hätte, im Fehlerfall das GetLastError auszuwerten.

[DeddyH]

Bei CreateProcess macht es einen Unterschied, ob man die Ansi- oder Unicode-Variante aufruft.

Zitat:

lpCommandLine [in, out, optional]

The command line to be executed. The maximum length of this string is 32,768 characters, including the Unicode terminating null character. If lpApplicationName is NULL, the module name portion of lpCommandLine is limited to MAX_PATH characters.

The Unicode version of this function, CreateProcessW, can modify the contents of this string. Therefore, this parameter cannot be a pointer to read-only memory (such as a const variable or a literal string). If this parameter is a constant string, the function may cause an access violation.

Bei ShellExecuteEx habe ich zumindest im MSDN keinen derartigen Hinweis entdecken können.