Shellexecute und Word

[wurzelsepp1]

Moin Gemeinde,

mal wieder eine einfache Frage:

Ich möchte ein Word-Dokument mit Word öffnen und verwende dazu Shellexecute.

Rufe ich die Funktion mit Pfad- und Dateiangabe auf, funktioniert alles. Beim Aufruf mit einer Variablen, die den selben Pfad enthält bekomme ich einen Code 2 zurück.


Beispiel hardcoded = funktioniert:

iReturnVal := ShellExecute(0, nil, 'C:\Users\jupp\Office-Dokumente\Serienbrief-Vorlage.dotx', nil, nil, 0);

Beispiel mit Variable = funktioniert nicht:

Delphi-Quellcode:

  getmem(pDatei, 256);
  sDatei := DateiscEdit.Text;
  pDatei := StringToWideChar(sDatei, pDatei, 256);

  iReturnVal := ShellExecute(0, 'open', pDatei, nil, nil, 0);

Das gleiche Konstrukt mit mailto funktioniert übrigens ..

Was mache ich da falsch?

Danke & schönen Abend,
alex

[Dalai]

Wir wissen nicht, wie pDatei definiert ist, und wir wissen auch nicht, ob in sDatei letztlich wirklich derselbe absolute Pfad drinsteht.

Aber es geht viel einfacher, und ohne viel Klimbim drumherum:

Delphi-Quellcode:

iReturnVal:= ShellExecute(0, 'open', PChar(sDatei), nil, nil, 0);
{oder auch}
iReturnVal:= ShellExecute(0, 'open', PChar(DateiscEdit.Text), nil, nil, 0);

Das Verb kann übrigens auch einen Unterschied machen, auch 'open' statt nil (wenn auch selten).

Grüße
Dalai

[wurzelsepp1]

Zitat von Dalai:

Aber es geht viel einfacher, und ohne viel Klimbim drumherum:

Delphi-Quellcode:

iReturnVal:= ShellExecute(0, 'open', PChar(sDatei), nil, nil, 0);
{oder auch}
iReturnVal:= ShellExecute(0, 'open', PChar(DateiscEdit.Text), nil, nil, 0);

Moin Dalai,

das war die Lösung: Mit PChar als Parameter läuft's.

Aber, für den Lerneffekt: Warum findet ShellExecute die Datei nicht, wenn ich die Stringumwandlung mit StringToWideChar mache?


VG
Alex

[himitsu]

Zitat von wurzelsepp1:

Warum findet ShellExecute die Datei nicht, ...

Man könnte die Fragen beantworten?
Vielleicht kommt dabei die (Er)Lösung.

Zitat von himitsu:

Was sagt denn der Debugger,
zum Inhalt von pDatei?

Welche Delphi-Version?

[himitsu]

Erstmal 2 = ERROR_FILE_NOT_FOUND bzw. SE_ERR_FNF

und steht im Edit wirklich genau das Gleiche, wie vorher in der Konstante?

Zitat von wurzelsepp1:

Beim Aufruf mit einer Variablen, die den selben Pfad

Dann hast du nicht nur die diesen einen Parameter getauscht.

das ist nicht das Selbe

Delphi-Quellcode:

  iReturnVal := ShellExecute(0, nil, ..., nil, nil, 0); 

  iReturnVal := ShellExecute(0, 'open', ..., nil, nil, 0);

Delphi-Quellcode:

  getmem(pDatei, 256);  <<<< 256 Bytes

  pDatei := StringToWideChar(sDatei, pDatei, 256); <<< 256 Chars

getmem(pDatei, 256 * SizeOf(Char));
ähhh
getmem(pDatei, MAX_PATH * SizeOf(Char));
nja
getmem(pDatei, (Length(sDatei) + 1) * SizeOf(Char));

Aber erstmal sind statische Buffer saublöd, (statisch = sich nicht an den Inhalt anpassend, vor allem wenn es zu klein sein könnte)
vor allem, da Microsoft seit Jahren versucht solchen Mist loszuwerden
https://learn.microsoft.com/de-de/wi...?tabs=registry

und irgendwelche Zahlen anstatt Konstanten sind noch unschöner.



Was sagt denn der Debugger,
zum Inhalt von pDatei?

Welche Delphi-Version?
Wenn nicht D2009 oder älter, dann selbst Schuld, wenn jemand (du) die Compilerwarnungen nicht liest.
https://www.delphipraxis.net/profile...le#csel_field5



Aber eignentlich würde ich eher solch unnützes Rumkopieren einfach lassen.

Delphi-Quellcode:

  iReturnVal := ShellExecute(0, nil, PChar(sDatei), nil, nil, 0); 

  iReturnVal := ShellExecute(0, nil, PChar(DateiscEdit.Text), nil, nil, 0);