Shellexecute richtig anwenden/übersetzen

[Delbor]

Hi zusammen
In einem in Javascript geschriebenen Beispielcode wird Shellexecute aufgerufen:


Ich hab im Editor 2 Zeilen, von denen die erste die Javascript-Schnipel wiedergibt und die 2. diie entsprechende Schreibweise in ObjectPascal definieren sollte.

Delphi-Quellcode:

    ShellExecute("RUNDLL32.exe", "PRINTUI.DLL,PrintUIEntry /k /n \"PDFCreator\"", "", "open", 1);
    ShellExecute('RUNDLL32.exe', 'PRINTUI.DLL,PrintUIEntry /k /n \'PDFCreator\'', '', 'open', 1);

Die ersten 2 Parameter sind String, bzw. PChar. Der 3. Parameter besteht ausdem Bezeichner PDFCreator, gefolgt von einem Backslash. Das ist insofern Korrekt, als Shellexecute an dieser Stelle tatsächlich keinen String erwartet.

Ich hab eigentlich nicht erwartet, dass das gleich funktioniert, insbesondere, da an shellexecute PChars übergeben werden müssen. Dass aber ein Kompilierungsversuch fehlschlägt, weil shellexecute unbekannt ist - in meiner Usesliste ist als erstes Winapi.Windows eingetragen ist - so hab ich denn ShellAPI dazugefügt. Komischerweise weiss Delphi selbst nichts von seinem guten Bekannten.
Ein kleiner Hinweis auf der entsprechenden Helpseite, und man wüsste, was einzubinden ist. Und die Entwicklung mit Delphi wäre noch schneller!
Gegenwärtiger Stand: wie ich erwartet hatte, moniert sich Delphi am Parameter PDFCreator. Die fehlenden PChar-Umwandlungen machen sich wohl erst später bemerkbar.
Aber was soll der Parameter PDFCreator sein? Das Handle der von der RunDll zu startenden Anwendung?

Gruss
Delbor

[Dalai]

Das "PDFCreator" ist keine Variable sondern einfach in Anführungszeichen gesetzt - daher auch die Backslashes jeweils vor den Quotes.

Grüße
Dalai

[Uwe Raabe]

Da in Delphi die Anführungszeichen ja eh anders sind, wäre die richtige Umsetzung dann wohl:

Delphi-Quellcode:

  ShellExecute('RUNDLL32.exe', 'PRINTUI.DLL,PrintUIEntry /k /n "PDFCreator"', '', 'open', 1);

[Delbor]

Hi zusammen
Danke euch beiden. PDFCreator ist somit eine Art "Mitparameter"...
Natürlich funktioniertdies aber immer noch nicht, da Shellexecute als ersten Parameter ein Handle erwartet. Dementsprechend meine Fehlermeldungen:

Zitat:

[dcc32 Fehler] PDFCreatorFrameUnit.pas(73): E2010 Inkompatible Typen: 'HWND' und 'string'
[dcc32 Fehler] PDFCreatorFrameUnit.pas(73): E2010 Inkompatible Typen: 'PWideChar' und 'Integer'
[dcc32 Fehler] PDFCreatorFrameUnit.pas(84): E2035 Nicht genügend wirkliche Parameter
[dcc32 Fataler Fehler] F2063 Verwendete Unit 'PDFCreatorFrameUnit.pas' kann nicht compiliert werden

Nachstehend 2 Zeilen aus dem Beispiel, das die Verwendung da aufzeigen soll:

Delphi-Quellcode:

var objShell = new ActiveXObject("Shell.Application");
...
...
objShell.ShellExecute("RUNDLL32.exe", "PRINTUI.DLL,PrintUIEntry /k /n \"PDFCreator\"", "", "open", 1);

Ich seh hier nicht die geringste Spur eines Handles. Selbst wenn der eigentliche Aufruf der Windowsfunktion Shellexecute in einer gleichnamigen Methode des JS-Objektes 'objshell' liegen würde (worauf dieser Code mE hinweist), müste dieesem das aktuele Handle mitgeteilt werden. Oder liege ich da falsch?

Gruss
Delbor

PS: Offenbar gar nicht so sehr...

[Hobbycoder]

So wie ich das sehe, wird das Handle da nicht benötigt.

https://docs.microsoft.com/en-us/win...l-shellexecute

[DeddyH]

Da wird wohl intern das Handle der Application übergeben. In Delphi kapselt Application.MessageBox ja auch die Win32-MessageBox, so dass man da kein Handle angeben muss.

[KodeZwerg]

Zitat:

Zitat von Uwe Raabe (Beitrag 1415781)

Da in Delphi die Anführungszeichen ja eh anders sind, wäre die richtige Umsetzung dann wohl:

Delphi-Quellcode:

  ShellExecute('RUNDLL32.exe', 'PRINTUI.DLL,PrintUIEntry /k /n "PDFCreator"', '', 'open', 1);

Delphi-Quellcode:

uses ShellApi;

...

function ExecuteShell(const Executable, Commands: String; const ShowConsole: Boolean): Cardinal;
 var
  ProcessInfo: TShellExecuteInfo;
 begin
  Result := Cardinal($FFFFFFFF);
  FillChar(ProcessInfo, SizeOf(TShellExecuteInfo), #0);
  with ProcessInfo do
  begin
   cbSize:= SizeOf( TShellExecuteInfo );
   fMask := SEE_MASK_NOCLOSEPROCESS or SEE_MASK_FLAG_DDEWAIT;
   Wnd := GetActiveWindow();
   lpVerb := 'open';
   lpFile:= PChar(Executable);
   lpParameters := PChar(Commands);
   lpDirectory := PChar(ExtractFilePath(Executable)); // <<-- diese zeile könnte probleme verursachen, eventuell anpassen (!)
   if ShowConsole then nShow := SW_SHOWDEFAULT else nShow := SW_HIDE;
  end;
  if ShellExecuteEx(@ProcessInfo) then
  begin
   if not GetExitCodeProcess(ProcessInfo.hProcess, Result) then Result := Cardinal($FFFFFFFF);
// GetExitCodeProcess(ProcessInfo.hProcess, Result);
   CloseHandle(ProcessInfo.hProcess);
  end
  else
  begin
   Result := GetLastError;
   exit;
  end;
 end;


...

ExecuteShell('RUNDLL32.exe', 'PRINTUI.DLL,PrintUIEntry /k /n "PDFCreator"', True);

Vielleicht klappt das?

[Delbor]

Hi KodeZwerg

Vielen Dank für deinen Code - funktioniert bestens und erzeugt mir so ein durchsuchbares Test-PDF. Alles, was mir jetzt noch bleibt,ist, die Quelle zu ändern - der Scanner liefert mir ein Bmp, bzw. ein von mir daraus erstelltes Jpeg. Aber das sollte eigentlich kein Problem mehr sein.

Gruss
Delbor

[KodeZwerg]

Freut mich das es klappt, nicht vergessen, habs oben nicht erwähnt, fehlercode prüfen/auswerten.
$FFFFFFFF = totaler fehler
nun kommt es darauf an,
man hat entweder den init-rückgabe wert der ShellExecuteEx oder einen vom System GetLastError auszuwerten.
shau am besten mal in doku nach dessen rückgabewerte, meine sind unbrauchbar/veraltet.
(ich kann dir mit dem creator nicht helfen, habe das teil nicht)

Viel Erfolg dabei, spiel damit ruhig rum, ich könnte mir vorstellen das lpDirectory in deinem speziellen fall (rundll) da ärger macht, aber wenn du bereits was damit erreichen konntest, um so besser :)

/edit
ps: ich habe es von hier, da stehen sehr viele varianten zur verfügung, im original ist auch noch eine "Warte" funktion, vielleicht wäre das sogar besser für dich?

[Dalai]

Zitat:

Zitat von Delbor (Beitrag 1415795)

Ich seh hier nicht die geringste Spur eines Handles.

Nur der Vollständigkeit halber: Die Windows API-Funktion ShellExecute aus Shell32.dll erwartet ein Handle und hat auch sonst eine andere Signatur (=Parameter), wie man in der MS-Doku zu dieser Funktion nachlesen kann. Delphi verwendet genau diese Funktion, nicht Shell.ShellExecute, das offenbar ein in Skriptsprachen (z.B. VB) übliches Shellobjekt ist.

Grüße
Dalai