*.Lnk Verknüpfungen funktionieren nicht.

[EWeiss]

Zitat:

Zitat von Daniel (Beitrag 1371219)

Emil - wir reden aneinander vorbei. Dein Screenshot zeigt den Windows-eigenen Dialog zu den Eigenschaften des Links. Schön und gut.
Relevant ist aber doch, was in Deinen Strings steht. Und das geht aus Deinen Screenshots nicht hervor. Auch wenn Du noch so sehr insistierst.
Im ersten Beitrag nutzt Du "ShellExecute", jetzt im letzten Beitrag "ShellExecuteAndWait", was eine eigene Routine ist - auch hier könnten Fehler verborgen sein.
Die Notation mit "@Path@" ist mir nicht bekannt und erscheint mir suspekt.

Rückgabewert von ShellExecute prüfen oder mit Werkzeugen wie dem ProzessExplorer von Microsoft mal schauen, wo Dein Programm hin will. Mehr fällt mir auch nicht ein.
ich bin jetzt aber auch raus.

Zitat:

Die Notation mit "@Path@" ist mir nicht bekannt und erscheint mir suspekt.

Das kann man sehen wie man will. Für mich ist das wichtig um den gesamt String zu parsen wie ich das nun im Code Händle sei mal dahingestellt.

Zitat:

Relevant ist aber doch, was in Deinen Strings steht.

Dort steht das was ich im vorherigen Beitrag geschrieben habe.

Zitat:

Dein Screenshot zeigt den Windows-eigenen Dialog zu den Eigenschaften des Links. Schön und gut.

Da sind 2 Kleine Bilder nicht gesehen ?
Dort steht der Komplette Pfad wie jetzt gepostet.

Wenn ich den Shortcut auslese bekomme ich diesen EXE-Pfad.
C:\Windows\Installer\{90160000-0011-0000-1000-0000000FF1CE}Icon.40BB677D.0A7A.4D43.9F72.5AE6F0E9 7EE2.exe
logischerweise wenn jemand mein Dokument als ScreenShot angesehen hätte wäre er alleine darauf gekommen.

also nun steht bei mir im Shellexecute string folgendes.
ShellExecuteAndWaitW(MainHandle, 'open', 'C:\Windows\Installer\{90160000-0011-0000-1000-0000000FF1CE}Icon.40BB677D.0A7A.4D43.9F72.5AE6F0E9 7EE2.exe', ''
'', SW_SHOW, true);

Das Problem ist nun der Pfad C:\Windows\Installer ist versteckt.
Wenn ich die Datei direkt im Ordner ausführen will kommt die Meldung "Ist keine zulässige Windows Anwendung"

Wenn ich aber den ShortCut auf dem Desktop direkt doppelklicke funktioniert das.
Und die Datei\Programm wird geöffnet.

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.

Zitat:

jetzt im letzten Beitrag "ShellExecuteAndWait", was eine eigene Routine ist - auch hier könnten Fehler verborgen sein.

Ja warum auch nicht.
Denn ich versuche auch nebenbei noch selbst auf die Lösung zu kommen.
Es könnte ja sein Das diese Anwendung eine gewisse zeit benötigt um zu starten und es deshalb nicht funktioniert.
Aber nach meinem Test liegt es daran definitiv nicht.

Ich habe auch schon die Attribute zugewiesen um versteckte Dateien lesen zu können
Aber ausführen lassen sie sich nicht.

Delphi-Quellcode:

fd.dwFileAttributes := 39; //NORMAL + READONLY + HIDDEN + SYSTEM + ARCHIVE

gruss

[bnreimer42]

Welche Windows-Version?

32 oder 64 Bit?

Ist die App 32 oder 64 Bit?

[EWeiss]

Zitat:

Zitat von bnreimer42 (Beitrag 1371224)

Welche Windows-Version?

32 oder 64 Bit?

Ist die App 32 oder 64 Bit?

64 Bit;
Aber 32Bit Anwendung.

gruss

[bnreimer42]

Habe gerade kein Delphi da, aber das klingt nach einem Problem mit dieser untransparenten Folderumleitung von 32 Bit Prozessen unter 64 Bit Windows.

Start über den Explorer = 64 Bit App greift auf exakt den geplanten Ordner zu.

Delphi 32 Bit App bekommt möglicherweise von Windows einen anderen Ordner virtuell reingemappt.

Kannst Du einfach mal ein ShellExecute reinbauen, bei dem Du nur den Ordner öffnest ohne Datei? Es sollte ein Explorer aufgehen,d er Dir genau zeigt, wo Deine Anwendung wirklich hin greift.

Ich kenne das insbesondere beim system32 Verzeichnis wo eine 32 Bit App beim Zugriff auf c:\windows\system32 in Wirklichkeit unter C:\Windows\SysWOW64 landet.

[EWeiss]

Zitat:

Kannst Du einfach mal ein ShellExecute reinbauen, bei dem Du nur den Ordner öffnest ohne Datei? Es sollte ein Explorer aufgehen,d er Dir genau zeigt, wo Deine Anwendung wirklich hin greift.

Ich denke das ist nicht so einfach.
Wenn ich die Anwendung nicht öffnen kann dann öffnet es mir auch nicht das Arbeitsverzeichnis dieser Anwendung.

Normale 32Bit Anwendungs-Verknüpfungen laufen hatte da bisher noch kein Problem.
Es ist ja nicht so das ich zu blöd dafür wäre die korrekten Parameter an ShellExecute zu übergeben aber anscheinend meinen das hier einige. ;)
Destotrotz scheint es wirklich unterschiede zu geben wenn man Verknüpfungen von 64Bit Anwendungen mit einer 32Bit Anwendung öffnen will.


gruss

[jaenicke]

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:

Zitat von EWeiss (Beitrag 1371221)

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...

[EWeiss]

Zitat:

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:

Ich verstehe nicht das ihr nicht versteht das es durchaus sinn machen kann wenn man dinge tut die andere nicht verstehen wollen oder können.
Aber das ist ganz einfach erklärt.

Ich habe eine Anwendung geschrieben die sich da nennt OverTheTaskbar. (OTTB.exe)
Das ist eine im Mac style ausgelegte Bar in der sich alle Anwendungen die man so benötigt integriert werden.

Es soll Leute geben die 30 > 100 Icons auf dem Desktop liegen haben.
Wenn meine Anwendung gestartet wird scannt diese alle Verknüpfungen auf dem Desktop und addiert diese zu OTTB.

Der Desktop wird dann stillgelegt und die Anwendungen können dann aus der Bar heraus gestartet werden.

Ich habe dann einen aufgeräumten Desktop und komme trotzdem noch an alle meine Daten.
Und nein falls diese Frage auftaucht.. es wird nichts gelöscht und die Icons vom Desktop können bei bedarf über ein Menü
wieder eigeschaltet werden.

Jetzt hänge ich doch nochmal ein Bild an.

Zitat:

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...

Nun dafür muss ich aber die Fehlerbehandlung nicht selbst gegenprüfen (Shellexecute bedingt) Windows macht das für mich.
Das wäre doppelt gemoppelt

gruss

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1371238)

Ich verstehe nicht das ihr nicht versteht das es durchaus sinn machen kann wenn man dinge tut die andere nicht verstehen wollen oder können.
Aber das ist ganz einfach erklärt.
[...]
Und nein falls diese Frage auftaucht.. es wird nichts gelöscht und die Icons vom Desktop können bei bedarf über ein Menü
wieder eigeschaltet werden.

Dann führe die Verknüpfungen doch einfach aus. Ansonsten bliebe nur die Funktionalität der explorer.exe nachzubilden, die eben nicht nur den Pfad aus der .lnk ausliest, sondern auch die genannten DLLs benutzt um den echten Pfad zu ermitteln.

Zitat:

Zitat von EWeiss (Beitrag 1371238)

Zitat:

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...

Nun dafür muss ich aber die Fehlerbehandlung nicht selbst gegenprüfen (Shellexecute bedingt) Windows macht das für mich.
Das wäre doppelt gemoppelt

Ich habe alles eben noch einmal durchgeschaut. Davon, dass der Fehler ist, dass die Datei nicht gefunden wurde, lese ich nirgends etwas. Wenn das auch so schon klar war ohne den Rückgabewert, dann wäre es schön gewesen das auch dazuzuschreiben...

[EWeiss]

Zitat:

Sprich die angegebene Exe aus der Verknüpfung existiert gar nicht.

Klar existiert die wer sagt dir das es nicht so ist?
OB sie nun ausführbar ist, das ist eine andere Geschichte.

Zitat:

Dann führe die Verknüpfungen doch einfach aus.

Theoretisch wäre es ja auch kein Problem es auf deine weise zu tun.
Aber praktisch ist es so das ich nicht auswählen kann was der User auf den Desktop legt.. Oder?

Und aussortieren kann ich da auch nichts.
Wiederum aus der Bar Anwendungen aus dem Startmenu zu starten macht keinen sinn.
Diese soll ja kein Ersatz für das Startmenu sein.

gruss

[Dalai]

Also, die EXEn in C:\Windows\Installer existieren natürlich, allerdings sind das KEINE normalen EXEn der jeweiligen Anwendungen sondern sie enthalten - wie der Dateiname auch schon vermuten lässt - lediglich Ressourcen, hier Icons.

Daher auch die Meldung "Ist keine gültige Win32-Anwendung". Ich habe mit dieser Geschichte auch schon zu tun gehabt, als ich ein Plugin für Total Commander schrieb und im Zuge dessen mit Verknüpfungen (LNKs) "rumgespielt" habe.

Lösung: LNK ausführen, ist viel einfacher. Es steckt in LNKs noch jede Menge Krempel, den man sonst von Hand nachbilden müsste.

Grüße
Dalai