Ich habe mir einmal angeschaut wie das funktioniert. Der Process Monitor wurde ja schon zweimal erwähnt. Da sieht man das sehr einfach.
Wenn die Verknüpfung ausgeführt wird, wird der Pfad gar nicht angesprochen. Stattdessen läuft das ganze aus der explorer.exe über die windows.storage.dll, die CommandLineFromMsiDescriptor aus der advapi32.dll aufruft und darin dann über MsiProvideComponentFromDescriptorW aus der
msi.dll und deren MsiGetComponentPathW den Pfad ermittelt.
Das passiert über den angegebenen Exe-Pfad über die entsprechende Registrierung in
HKCR\Installer\Features\00005109110000000100000000 F01FEC. Der Pfad zur Exe steht am Ende in
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Ins taller\UserData\S-1-5-18\Components\ FDB90FF6780B32E49A9B72D2FB6D0499\00005109110000000 100000000F01FEC. Und dann wird einfach die winword.exe in dem Pfad unter Program Files aufgerufen.
Sprich die angegebene Exe aus der Verknüpfung existiert gar nicht.
Ich verstehe allerdings auch nicht warum du die .lnk ausliest und ausführst anstatt einfach die Verknüpfung auszuführen. Dafür ist sie ja da. Das funktioniert hier auch problemlos:
Delphi-Quellcode:
ShellExecute(
Handle, '
open', '
explorer',
'
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office 2013\Word 2013.lnk', '
', SW_SHOW);
Zitat:
ShellExecute hat immer einen Rückgabewert. Und dein Problem ist doch, dass es nicht funktioniert, also wieso sollte der Rückgabewert nichts aussagen?
Ich sage nochmal den braucht man nicht denn Windows wirft die Meldung von selbst wenn was nicht stimmt.
Ohne das man sich da selbst noch mit rumschlagen muss.
Das passiert nur, wenn der Aufruf selbst klappt und dann danach etwas schief geht. Zum Beispiel wenn die explorer.exe aufgerufen wird und dann dort etwas schief geht.
In diesem Fall liefert ShellExecute aber 2 zurück, was
laut Doku heißt (
oh Wunder) ERROR_FILE_NOT_FOUND. Hättest du gleich dies geschrieben, wären wir schon längst weiter gewesen...