Ordnung muss sein (LaunchBar)

[KodeZwerg]

Ich weiß ja nicht ob für Dich akzeptabel mit den Uses, in meinem non-Vcl ist das Kontroproduktiv.

Das löst aber dieses "hab nix Icon Problem" für 64bit .exe Verknüpfung aus \Program Files\, ob Admin oder Gast, beides klappt.

Dann halt Record auswerten ob FullPathAndNameOfFileContiningIcon oder FullPathAndNameOfFileToExecute zu nutzen ist, jeweils mit IconIndex auswerten = Man hat mit 32bit auch 64bit .exe Icons von Verknüpfung.

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1410939)

Ich weiß ja nicht ob für Dich akzeptabel mit den Uses, in meinem non-Vcl ist das Kontroproduktiv.

Das löst aber dieses "hab nix Icon Problem" für 64bit .exe Verknüpfung aus \Program Files\, ob Admin oder Gast, beides klappt.

Dann halt Record auswerten ob FullPathAndNameOfFileContiningIcon oder FullPathAndNameOfFileToExecute zu nutzen ist, jeweils mit IconIndex auswerten = Man hat mit 32bit auch 64bit .exe Icons von Verknüpfung.

Ich möchte nicht von meiner uIShellItem.pas abweichen denn dann müsste ich für dieses eine Problem alles neu schreiben.
Das wäre dann doch zu viel des guten ;)

Zitat:

Damit kompiliert Emils SourceCode völlig problemlos

Ja sollte kein Problem sein.. Aber jetzt kommt das große ABER.. Die Dateien sind dann kompiliert 3x mal so groß.

gruss

[KodeZwerg]

Öhmm, Danke für den Tipp mit Unit Namen, hab da mal reingeschaut.

Delphi-Quellcode:

  TWin32ShortCut = class(TBaseShortcut)
    private
      FShellLink: IShellLink;
      FPersistFile: IPersistFile;
      FAppPath: String;
      FRelativePath: String;
      FPIDL: PItemIDList;
      FWorkDirectory: String;
      FArguments: String;
      FDescription: String;
      FShowCmd: TShowType;

Du hast doch bereits alles, ich schau mal ob ich in der Lage bin mit dieser Unit ein D2009 Projekt zum Laufen bekomme. Ansonsten ist Sonntag CE fällig :)

edit
Nicht mehr jetzt, Gute Nacht.

[KodeZwerg]

Hello Emil!

Also ich habe mich nochmal dem Thema lnk Datei gewidmet.
Bin mit einer Vcl Testanwendung auch zu ein paar Ergebnissen gekommen.
Siehe Anhang 49774
Was da völlig falsch läuft ist wie dieser ShortCut aufgelöst wird.
Wahrscheinlich da meine Anwendung 32bit ist ersetzt Windows die Quelle automatisch.
Wenn ich mir die Link Datei mit einem HexEdit betrachte, da steht nix von (x86) im Pfad.

Also meine momentane Lösung ist mehr als dürftig.

[EWeiss]

Zitat:

Was da völlig falsch läuft ist wie dieser ShortCut aufgelöst wird.

Na ja ist nicht nur dieser es sind alle ShortCut von Anwendungen unter Program Files.

gruss

[KodeZwerg]

Jupp, deswegen Suche ich nach einer anderen Methode eine .lnk Datei zu entziffern als über ComObj. Da greift Windows ein und ich kann nichts machen ausser die .exe mit dem Working Path zu parsen, was irgendwie nicht Sinn und Zweck der Sache ist.
Ich schau mir mal an ob ich ne .lnk nicht auch Binär auslesen kann, muss doch machbar sein so was.

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1410988)

Jupp, deswegen Suche ich nach einer anderen Methode eine .lnk Datei zu entziffern als über ComObj. Da greift Windows ein und ich kann nichts machen ausser die .exe mit dem Working Path zu parsen, was irgendwie nicht Sinn und Zweck der Sache ist.
Ich schau mir mal an ob ich ne .lnk nicht auch Binär auslesen kann, muss doch machbar sein so was.

Habe schon einiges versucht Adminrechte im Manifest..
Die Attribute selbst zu ändern und, und muss noch mal debuggen eventuell ein Problem im Code selbst wie beim "Installer Path"

gruss

[KodeZwerg]

Ich gehe immer noch davon aus das es nicht die Admin oder Zugriffs Rechte sind sondern die Art und Weise wie Windows Programm-Anfragen bedient.
Schau Dir doch mal so eine Link Datei näher an Anhang 49775
Obwohl ein fester .exe Pfad angegeben, greift Windows nicht darauf zu sondern bastelt sich die Informationen aus CSIDL und dem Solo-Namen zusammen, so ist jedenfalls meine Vermutung nach etlichen Tests unter Aufsicht von FileMon/ProcMon.

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1410997)

Ich gehe immer noch davon aus das es nicht die Admin oder Zugriffs Rechte sind sondern die Art und Weise wie Windows Programm-Anfragen bedient.
Schau Dir doch mal so eine Link Datei näher an Anhang 49775
Obwohl ein fester .exe Pfad angegeben, greift Windows nicht darauf zu sondern bastelt sich die Informationen aus CSIDL und dem Solo-Namen zusammen, so ist jedenfalls meine Vermutung nach etlichen Tests unter Aufsicht von FileMon/ProcMon.

Ok ;) Danke
Ich muss mich erst mal um ein anderes Problem kümmern, die Qualität der Icons ist schlecht.

gruss

[jaenicke]

Zitat:

Zitat von KodeZwerg (Beitrag 1410997)

Obwohl ein fester .exe Pfad angegeben, greift Windows nicht darauf zu sondern bastelt sich die Informationen aus CSIDL und dem Solo-Namen zusammen, so ist jedenfalls meine Vermutung nach etlichen Tests unter Aufsicht von FileMon/ProcMon.

Da brauchst du nicht viel testen. Nimm einfach einen Hexeditor und überschreibe z.B. das Program aus Program Files in dem Pfad. Rufst du dann aber GetPath auf, bekommst du trotzdem Program Files (x86).
Der Grund ist wie vermutet, dass beim Laden des Links die darin enthaltenen CLSIDs aufgelöst werden. Das kann man leicht testen, indem man einen Haltepunkt auf die entsprechende API-Funktion SHGetKnownFolderPath setzt. Die wird dabei nämlich aufgerufen.

Die sinnvollste Lösung dafür ist tatsächlich einfach auf 64-Bit zu gehen, wenn man diese Information benötigt.

Ich selbst habe .lnk Dateien immer lediglich an ShellExecute gefüttert, habe aber den Pfad dort nicht ausgelesen. Den Pfad zu nehmen um den Prozess zu starten ist keine so gute Idee, da man damit alle solchen "Features" zur Auflösung der korrekten Pfade übergeht. Und zur Anzeige könnte man ihn manuell aus der .lnk Datei herausfriemeln.