*.Lnk Verknüpfungen funktionieren nicht.

[EWeiss]

Um zu verstehen was ich meine ist es nötig die Bilder anzusehen.
Diese Verknüpfung über ShellExecute funktioniert nicht.

jemand einen Ahnung warum das so ist?

Delphi-Quellcode:

procedure StartApplication(nItem: integer);
var
  sShellTo, sCmdLine, sFullPath: string;
begin
  sShellTo := gS[nItem].ShellTo;
  if InStr(0, sShellTo, '{') <> 0 then
    sShellTo := '';

  sFullPath := gS[nItem].WorkDir;
  sCmdLine := gS[nItem].CmdLine;
  sCmdLine := StringReplace(sCmdLine, ';', ',', [rfReplaceAll]);

  if Length(sFullPath) = 0 then
    sFullPath := RightTrim(ExtractFilePath(sShellTo))
  else
    SetCurrentDirectory(PWideChar(sFullPath));

  ShellExecute(0, 'open', PWideChar(sShellTo), PWideChar(sCmdLine), PWideChar(sFullPath),
    gS[nItem].ShowCmd);

end;

Sogar mit Ziel und Ausführen in funktioniert es nicht.

gruss

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1371209)

Um zu verstehen was ich meine ist es nötig die Bilder anzusehen.

Nein?

Was geht nicht?
Vorallem was steht in welche Variable drin?

Und ich kann rein garnichts erkennen, was mit einer LNK-Datei zu tun haben soll.
Wie/Wo wird da auf so eine Datei zugegriffen und wie werden die Werte dort ausglesen.
Bzw. wie sieht diese Datei aus?

Manchmal kann es auch nicht schaden, wenn man "Sonderfunktionen" erklärt, die nicht standardmäßig im Delphi enthalten sind.
PoSex / ContainsStr
Oder den Code kommentiert, denn ich kann z.B. keinen Sinn darin erkennen, warum da TrimRight oder das SetCurrentDirectory im Code drin ist.

Und warum im Himmels Willen wertet Niemand die Rückgabewerte von ShellExecute aus?
Man mag es nicht glauben, aber die WinAPI sagt einem manchmal sogar, warum etwas nicht funktioniert. :roll:

[EWeiss]

Zitat:

Nein?

Soll ich dir darauf antworten wenn du nein sagst ?

Warum Antwortest du wenn du die Bilder nicht ansehen möchtest
ohne das du das tust und den Link der EXE Datei anschaust wirst du mir auch nicht helfen können.

gruss

[Daniel]

Deine Antwort könnte in weiteren Informationen bestehen.
Und Dein Problem ist auch nicht, dass Verknüpfungen im Allgemeinen nicht funktionieren, sondern dass das Auslesen der Pfade offenbar ein Problem bereitet.

Himitsu hat Dir einen wichtigen Tipp gegeben: Den Rückgabewert von ShellExecute() auszuwerten. Ansonsten versuche es mal mit einem kurzen Pfad ohne Leerzeichen. Eventuell fehlen nur die doppelten Anführungszeichen.

[Der schöne Günther]

Er hat doch völlig Recht. Die Bildchen helfen niemand. Der Code ebenso, denn niemand kann riechen was in den Variablen steckt.

Edit: Hoppla, der rote Kasten schläft noch.

[EWeiss]

Zitat:

Himitsu hat Dir einen wichtigen Tipp gegeben: Den Rückgabewert von ShellExecute() auszuwerten. Ansonsten versuche es mal mit einem kurzen Pfad ohne Leerzeichen. Eventuell fehlen nur die doppelten Anführungszeichen.

Die Rückgaben sagen gar nichts aus wenn keine kommen. (Diese sind NUR wichtig wenn Fehler auftreten sollten ) tun sie aber nicht.

Zitat:

Er hat doch völlig Recht. Die Bildchen helfen niemand.

Aber ohne diese wirst du den ellenlangen Pfad den ich hier nicht eintippen will nicht sehen können.
So einfach ist das.
Die habe ich nicht angehängt weil sie schön sind sondern zu Dokumentations zwecken.

Zitat:

sondern dass das Auslesen der Pfade offenbar ein Problem bereitet.

Nö sondern dass das starten des Programms über den Pfad wie er im Bild ersichtlich ist nicht funktioniert.

Zitat:

Und ich kann rein garnichts erkennen, was mit einer LNK-Datei zu tun haben soll.

Du weist nicht was eine Verknüpfung ist? NA dann.

gruss

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1371214)

Die Rückgaben sagen gar nichts aus wenn keine kommen. (Diese sind NUR wichtig wenn Fehler auftreten sollten ) tun sie aber nicht.

ShellExecute hat immer einen Rückgabewert. Und dein Problem ist doch, dass es nicht funktioniert, also wieso sollte der Rückgabewert nichts aussagen?

Rückgabewerte nicht zu behandeln heißt:
"Mach mal, aber wenn es nicht geht, ist es mir auch egal."
Wenn es dir nicht egal ist, ob es nicht funktioniert, solltest du die Rückgabewerte auch behandeln um ggf. eine passende Fehlermeldung auszugeben.

Wenn der Rückgabewert von ShellExecute wirklich sagt alles ok, bleibt nur noch mit Tools wie dem Process Monitor zu schauen warum das erfolgreich gestartete Programm (Rückgabewert alles ok, also wurde es gestartet) abstürzt.

[Daniel]

Was steht denn in Deinen Strings, die Du an ShellExecute übergibst?

[EWeiss]

Zitat:

Zitat von Daniel (Beitrag 1371217)

Was steht denn in Deinen Strings, die Du an ShellExecute übergibst?

Dafür muss man sich mein Dokument in Bildform ansehen da steht der Name der Exe.

Delphi-Quellcode:

ShellExecuteAndWaitW(MainHandle, 'open', PWideChar(sShellTo), PWideChar(sCmdLine),
  PWideChar(sFullPath), gS[nItem].ShowCmd, true);

Parameter:
'ShellTo, UseLabel, IconName, WorkDir, CmdLine, EnableShortcutTrueFalse'
Zu Parsender String
"explorer.exe, Win7(C:), @PATH@UserIcon\48x48\HD.png, @PATH@, C:\, 1"


sShellTo = explorer.exe
sUseLabel = Win7(C:)
sUseThumb = @PATH@UserIcon\48x48\HD.png
sFullPath(Workdir) = ''
sCmdLine = C:\
gS[nItem].ShowCmd := SW_SHOW

Als Beispiel.

gruss

[Daniel]

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.

[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

[EWeiss]

Zitat:

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

Die frage ist nur wie soll ich den Pfad parsen wenn ich die Shortcuts vom Desktop einlese.
Denke mal das sollte nicht so einfach sein.

Denn wie gesagt ich möchte keine Dateien vom Startmenu addieren.
Und wenn jemand Word auf den Desktop abgelegt hat was dann ?

Zitat:

lediglich Ressourcen, hier Icons.

Ja deshalb bekomme ich bei einigen auch das Package Icon geliefert anstelle das von der EXE.

gruss

[jaenicke]

Zitat:

Zitat von Dalai (Beitrag 1371251)

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.

Bei mir nicht. Weder Windows noch Linux finden dort den Ordner. Und laut Process Monitor gibt es zumindest beim Starten der Verknüpfung für Word 2010 auch keinen Zugriff darauf.

[EWeiss]

Zitat:

Zitat von jaenicke (Beitrag 1371254)

Zitat:

Zitat von Dalai (Beitrag 1371251)

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.

Bei mir nicht. Weder Windows noch Linux finden dort den Ordner. Und laut Process Monitor gibt es zumindest beim Starten der Verknüpfung für Word 2010 auch keinen Zugriff darauf.

Du musst die Order Eigenschaften so einstellen das du geschützte Dateien und Ordner einblendest.
Danach kannst du auch den Installer Ordner unter Windows finden.

gruss

[nahpets]

Eventuell liege ich ja vollkommen daneben, aber ich würde mir vom Desktop einfach alle Links sammeln (oder was ich sonst so auswählen möchte) und die dann in der Form starten:

Delphi-Quellcode:

ShellExecuteAndWaitW(MainHandle, 'open', PWideChar(sPfadUndNameDerLinkdatei), '', '', gS[nItem].ShowCmd, true);

Windows kann dann mit seiner "eingebauten Logik" für den entsprechenden Programmstart (unter Auswertung aller in der Linkdatei enthaltenen Konfigurationen) sorgen.

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1371255)

Du musst die Order Eigenschaften so einstellen das du geschützte Dateien und Ordner einblendest.
Danach kannst du auch den Installer Ordner unter Windows finden.

Den Ordner gibt es auch und darunter auch viele andere, aber eben nicht den genannten. Und bei mir kommt ja auch, dass die Datei nicht gefunden wird.

Für die Ausführung ist die Datei also definitiv nicht nötig. Das Icon könnte im Cache liegen.

[EWeiss]

Zitat:

Zitat von nahpets (Beitrag 1371262)

Eventuell liege ich ja vollkommen daneben, aber ich würde mir vom Desktop einfach alle Links sammeln (oder was ich sonst so auswählen möchte) und die dann in der Form starten:

Delphi-Quellcode:

ShellExecuteAndWaitW(MainHandle, 'open', PWideChar(sPfadUndNameDerLinkdatei), '', '', gS[nItem].ShowCmd, true);

Windows kann dann mit seiner "eingebauten Logik" für den entsprechenden Programmstart (unter Auswertung aller in der Linkdatei enthaltenen Konfigurationen) sorgen.

Geht nicht so einfach.
Denn es gibt unter umständen mehrere Benutzer am Computer da kann man nicht sicher sein ob man einen zugriff auf den Desktop Order des jeweiligen Users bekommt.

Auf der anderen Seite gibt es ja auch so etwas.

Zitat:

"explorer.exe, Papierkorb, @PATH@UserIcon\48x48\RecycleBinFull.png, , /N;::{645FF040-5081-101B-9F08-00AA002F954E}, 2"

Das ist so pauschal gesagt nicht so einfach das alles unter einen Hut zubringen.
Dann verzichte ich lieber auf Office. ;)

Aber wenn dann wäre dieser weg den Desktop Ordner zu durchsuchen der richtige.

gruss

[EWeiss]

Zitat:

aber eben nicht den genannten.

Nein kann auch nicht.
Es sei denn du hast Office 2016 installiert.
So wie ich das aber sehe sind fast alle 64Bit installierten Anwendungen dort vertreten.
Darauf habe ich dann auch keinen zugriff.

gruss

[Dalai]

Zitat:

Zitat von EWeiss (Beitrag 1371253)

Denn wie gesagt ich möchte keine Dateien vom Startmenu addieren.

Was hat das Startmenü damit zu tun? Du gibst ShellExecute einfach direkt die LNK, ist doch kein Problem. Oder übersehe ich was?

Zitat:

Und wenn jemand Word auf den Desktop abgelegt hat was dann ?

Was soll dann anders sein?

Zitat:

Zitat von jaenicke

Bei mir nicht. Weder Windows noch Linux finden dort den Ordner. Und laut Process Monitor gibt es zumindest beim Starten der Verknüpfung für Word 2010 auch keinen Zugriff darauf.

Ein Zugriff beim Starten der Software ist auch nicht nötig, denn das Icon wird daraus schon wesentlich früher gelesen, sofern es nicht eh bereits aus dem Iconcache ausgelesen wurde. Der Name des Ordners hängt natürlich von der Software und deren Version ab. Adobe Reader ist auch ein Kandidat, der seinen Krempel dort hinterlegt. Und es gibt noch weitere Programme, deren Setup auf Windows Installer oder InstallShield (Wrapper um MSI) basiert.

Grüße
Dalai

[EWeiss]

Zitat:

denn das Icon wird daraus schon wesentlich früher gelesen, sofern es nicht eh bereits aus dem Iconcache ausgelesen wurde.

Woher willst du das so genau wissen wann ich das Icon einlese?

Zitat:

Was hat das Startmenü damit zu tun? Du gibst ShellExecute einfach direkt die LNK, ist doch kein Problem. Oder übersehe ich was?

Wie ich schon schrieb die Pfade sind nicht nur für die *.lnk Dateien ausgelegt sondern für unterschiedliche.

Es gibt *.URL, *.lnk und User definierte Ausführbare Icons auf der Bar.
Für euch außenstehende ist das kein Problem... ja mach mal eben. ;) Aber ihr kennt den Aufwand nicht der betrieben werden muss
damit das nachher auch alles seine Richtigkeit hat.

Aber gut habe eine Lösung gefunden.

Ich prüfe ob ein Link existiert. If DoLnk >>
dann übergebe ich normalerweise den Target Pfad also den wo sich die Exe befindet.

Delphi-Quellcode:

      if DoLnk then
      begin
        gS[nCount].ShellTo := Lowercase(sTarget); // <<<< Target = 'C:\Windows\Installer\{90160000-0011-0000-1000-0000000FF1CE}Icon.40BB677D.0A7A.4D43.9F72.5AE6F0E9 7EE2.exe'
        gS[nCount].WorkDir := PWideChar(pLnk.WorkDir);
        gS[nCount].CmdLine := PWideChar(pLnk.Arguments);
        gS[nCount].ShowCmd := integer(pLnk.ShowCmd);
        gS[nCount].CtrlName := sTxt;
        gS[nCount].CtrlIndex := nCount;
      end;
      gS[nCount].UseLabel := sTxt;

den ändere ich jetzt um auf

Delphi-Quellcode:

gS[nCount].ShellTo := Lowercase(sFullName); // <<<< 'C:\Users\Gast\Desktop\Word 2016.lnk'

damit sollte das Problem erstmal erledigt sein. (Muss das aber noch überwachen).

gruss

[EWeiss]

OK jetzt geht's hab euch noch ein paar Herzen hinzugemacht. LOL
Die Herzen sind Verknüpfungen der Rest ist vordefiniert in meiner Config Datei.

gruss

[Dalai]

Zitat:

Zitat von EWeiss (Beitrag 1371268)

Woher willst du das so genau wissen wann ich das Icon einlese?

Ich bezog mich auf das Einlesen durchs System, um das Icon für die Verknüpfung darstellen zu können. Aber ja, es könnte sein, dass das durch deinen Code ausgelesene Icon ebenfalls aus dem Iconcache stammt; ich hab kein tiefergehendes Wissen, wie Windows diesbzgl. arbeitet.

Zitat:

Es gibt *.URL, *.lnk und User definierte Ausführbare Icons auf der Bar.
Für euch außenstehende ist das kein Problem... ja mach mal eben. ;) Aber ihr kennt den Aufwand nicht der betrieben werden muss
damit das nachher auch alles seine Richtigkeit hat.

Nun, allein aus dem OP und den ersten paar Posts kann man diese Details nicht ablesen. Insofern kann daraus keiner den Aufwand abschätzen.

Grüße
Dalai

[EWeiss]

Ach egal ;)

Es funktioniert ja jetzt mit eurer Idee.
Danke!

Hoffe die Herzchen sind dank genug... LOL (wenn ihr sie dann anschaut.)

Zitat:

Ich bezog mich auf das Einlesen durchs System, um das Icon für die Verknüpfung darstellen zu können.

Ach so..
Ich habe die lade Routine der Icons jetzt nicht verändert diese werden immer noch aus dem Target Pfad gelesen (direkt aus der EXE)
Sieht zwar blöd aus da manche hier das Package Icon abgelegt haben aber was soll's.

gruss

[EWeiss]

Zitat:

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

Nur nochmal zur Auffrischung und eine kleine Erklärung.

Im Grunde genommen muss man das als Platzhalter verstehen klar hätte ich auch "Hänschen" benennen können. ;)
Im Code prüfe ich ob der Anwendungspfad der gleiche ist wie der Arbeitspfad wenn das zutrifft wird der Arbeitspfad
durch diese Variable ersetzt um nicht ellenlange Strings in die Konfigurationsdatei zu schreiben.

bsp:
@PATH@UserIcon\48x48\Prompt.png := Der Anwendungspfad + der Ordner wo sich die Icons befinden.
Ich denke auf diese Art einen Platzhalter zu definieren ist durchaus angebracht.

Oder der Anwendungspfad zu meiner Anwendung.

Jetzt!

Zitat:

"c:\program files (x86)\microsoft visual studio\vb98\sourcemein\skaero projekte\sound machine\_build\soundmachine.exe, Soundmachine, @PATH@UserIcon\48x48\SoundMachine.png,@PATH@, 1'"

Und ohne Platzhalter

Zitat:

"c:\program files (x86)\microsoft visual studio\vb98\sourcemein\skaero projekte\sound machine\_build\soundmachine.exe, Soundmachine, c:\program files (x86)\microsoft visual studio\vb98\sourcemein\skaero projekte\sound machine\_build\UserIcon\48x48\SoundMachine.png, c:\program files (x86)\microsoft visual studio\vb98\sourcemein\skaero projekte\sound machine\_build\, , 1'"

So wie oben bleibt das wenigstens noch Lesbar.
Aber gut sei's drum.
--------------------
Mit den Verknüpfungen bin ich noch nicht durch.
Wenn ich jetzt direkt die *.lnk Dateien als Anwendungspfad angebe gibt es Probleme wenn der User diese vom Desktop entfernt.
Es gibt dann auch noch das Problem das die User definierten Icons dann für *.lnk Dateien unnötig sind zudem wird die Konfiguration dann unbrauchbar.

Eventuell muss ich den String parsen und nach dem Namen Icon scannen
Und nur dann wenn dieser existiert den Anwendungspfad austauschen mit dem vom Desktop wo die Verknüpfung abgelegt ist.
C:\Windows\Installer\{90160000-0011-0000-1000-0000000FF1CE}Icon.40BB677D.0A7A.4D43.9F72.5AE6F0E9 7EE2.exe
Ich denke das sollte auf allen Windows verschiedener Sprachen gleich sein.

Auf "C:\Windows\Installer\" hin zu prüfen dürfte fehlschlagen.

PS:
Habe jetzt nochmal alles umgebaut es werden jetzt nur noch positive Array Indexes verwendet.

gruss

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1371398)

Wenn ich jetzt direkt die *.lnk Dateien als Anwendungspfad angebe gibt es Probleme wenn der User diese vom Desktop entfernt.

Ich würde die intern benutzten Verknüpfungen schlicht in das Anwendungsdatenverzeichnis deines Programms kopieren und dann dort benutzen.
Wenn du die .lnk Dateien ausliest und die Daten irgendwo speicherst, machst du ja im Grunde auch nichts anderes.

[EWeiss]

Zitat:

Ich würde die intern benutzten Verknüpfungen schlicht in das Anwendungsdatenverzeichnis deines Programms kopieren und dann dort benutzen.

Wenn der User diese löscht dann ist es fraglich diese in den Anwendungspfad zu kopieren.
Er wird ja einen Grund haben warum er sie löscht.

Es ist ja nicht so das die Anwendung dadurch abstürzt.
Nur die Anzeige der Icons auf der Bar sind dadurch beeinträchtigt.

gruss

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1371401)

Er wird ja einen Grund haben warum er sie löscht.

Es ist ja nicht so das die Anwendung dadurch abstürzt.
Nur die Anzeige der Icons auf der Bar sind dadurch beeinträchtigt.

Wenn die echte .lnk nicht mehr da ist, musst du ja das Ausführen nicht mehr zulassen. Ich finde es aber auch nicht schlimm, wenn das Icon dann kaputt ist. Ich meine löschen ist löschen...
Es macht denke ich eher Sinn den Eintrag schlicht zu entfernen, denn ich habe das so verstanden, dass das ein Abbild der Desktop Icons sein soll, oder?

// EDIT:
Viel schöner wäre da allerdings ein Tool, dass die auch direkt ins Startmenü einklappern kann. Wenn ich irgendwo einen Rechner einrichte, dauert es immer recht lange die alle anzuklicken und da hinein zu befördern...
Aber ich glaube das ist (aus gutem Grund...) nicht vorgesehen.

[EWeiss]

Zitat:

Viel schöner wäre da allerdings ein Tool, dass die auch direkt ins Startmenü einklappern kann.

Das ist keine schlechte Idee. ;)

Ich möchte aber eigentlich nur dafür sorgen das der Desktop aufgeräumt wird.
Ohne Daten zu verändern, verschieben oder sonstiges.
Ich möchte also nicht so tief in das System eingreifen, so das ich nachher besondere Rechte für das Programm benötige.

Es ist am ende nur eine Schnellstart Leiste die man seinen Ansprüchen entsprechend anpassen kann.

gruss

[HolgerX]

Und noch ein Hinweis zu lnk-Dateien:

Sie speichern noch MEHR als nur das Icon und die Pfade!
Somit solltest du immer ShellExcec mit der Lnk-Datei machen.

In der Lnk-Datei stehen weitere Konfigurationen wie:
- Kompatibilitätsmodus
- Fenstergröße/Schriftart.. (bei z.B. Batchprogrammen bzw. Dos-Programmen).
- Sogar Zugriffsrechte..
- ...

Diese würdest du komplett verlieren, wenn du nur die Anwendungsdatei berücksichtigst zum Aufruf verwendest.

Und wenn die lnk-Datei vom User entfernt wurde, dann sollte diese auch bei dir entfernt werden. Schließlich will das der User so... ;)

[EWeiss]

Zitat:

Somit solltest du immer ShellExcec mit der Lnk-Datei machen.

Ich sagte schon das kann bzw. will ich nicht weil hier noch einige andere Dinge Bezug darauf nehmen.
Man kann nicht pauschal sagen man sollte immer... sicher das ist der einfachste weg aber nicht immer der sinnvollste.
Abhängig von dem was sonst noch an dem Programm dranhängt.

Ich hoffe das kommt jetzt nicht wieder überheblich oder falsch rüber.

Zitat:

Und wenn die lnk-Datei vom User entfernt wurde, dann sollte diese auch bei dir entfernt werden. Schließlich will das der User so...

Das ist auch so nach einem Restart des Programms.. solange wie die Konfiguration nicht abgespeichert wurde werden die Verknüpfungen bei jedem Start neu eingelesen.
Also wenn er sie dann gelöscht hat werden sie auch nicht mehr addiert.

Wurde sie jedoch gespeichert dann ist immer noch ein Icon in der Bar das dann aber Leer ist.
Es liegt dann an ihm selbst das in der Konfigurationsdatei zu beheben.

Zitat:

Diese würdest du komplett verlieren, wenn du nur die Anwendungsdatei berücksichtigst zum Aufruf verwendest.

Nein, nein unabhängig davon ob ich diese über den Anwendungspfad starte verliere ich die nicht denn diese Daten stehen dann alle schon in meinem Array.
Also was ich so brauche.

Delphi-Quellcode:

  TSprite = packed Record
    CtrlName: WideString;
    CtrlIndex: Integer;
    Left: Single;
    Top: Single;
    Width: Integer;
    Height: Integer;
    Scale: Single;
    Opacity: Byte;
    ShellTo: string;
    IconPath: WideString;
    WorkDir: WideString;
    UseLabel: string;
    CmdLine: WideString;
    ShowCmd: LongInt;
    h_Bitmap: HBitmap;
    Visible: Bool;
  End;

gruss

[madas]

Zitat:

Zitat von EWeiss (Beitrag 1371238)

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.

Hm es soll Leute geben, bei denen liegt nur der Papierkorb auf dem Desktop. Was bringt Dein Programm diesen Leuten für Vorteile?
Mal ehrlich: Anwendungen, die man sehr häufig benutzt (mehr als 10-15 Stück werden das bestimmt nicht sein), kommen in die Windows-Standard-Taskbar.
Der Rest ist über Windows-Taste und Eingabe des Programmnamens sehr leicht zu finden bzw. zu starten. Daher erschließt sich mir der Sinn Deines
Taskbar-Aufsatzes nicht wirklich. :gruebel: