PIDL und der Font-Ordner - geht nicht

[MicMic]

Hallo,
für manche Operationen konvertiere ich ein Pfad+Dateiname zu ein PIDL Dingsbums.

Delphi-Quellcode:

function PathToPIDL(APath: WideString): PItemIDList;
var
  Desktop: IShellFolder;
  pchEaten, dwAttributes: ULONG;
begin
  Result := nil;
  SHGetDesktopFolder(Desktop);
  dwAttributes := 0;
  if Assigned(Desktop) then
  begin
    if Desktop.ParseDisplayName(0, nil, PWideChar(APath), pchEaten, Result, dwAttributes) <> NOERROR then
      Result := nil;
  end
end;

Dies geht soweit aber im Font-Ordner (C:\Windows\Fonts). Also wenn ich dort im Ordner eine Schriftartdatei auf die Funktion feuere, bekomme ich bei "ParseDisplayName" einen Fehlercode (E_INVALIDARG) zurück. Schlimmer noch, dass "ParseDisplayName" hier dann noch zu lange braucht und meine Routine abbremst. Der Ordner wird auch von Windows irgendwie speziell behandelt. Auf eine Schriftartdatei kann man z.B. kein Eigenschaftsdialog anzeigen lassen. Dies geht erst, wenn man eine Datei herauskopiert. Alles irgendwie mal wieder nicht zu verstehen. Hat jemand Rat?

Gruß Mike

[KodeZwerg]

SHGetKnownFolderPath mit FOLDERID_Fonts sollte klappen.


/edit
upps, sorry, hab jetzt erst verstanden was du vorhast, vergiss das obige, tut mir leid!

[KodeZwerg]

Hab vielleicht doch noch was passendes... ILCreateFromPath

Delphi-Quellcode:

// falls das Windows.pas nicht hat:
function ILCreateFromPath(pszPath: LPCWSTR): PItemIDList; stdcall
external shell32 name 'ILCreateFromPathW';

// der eigentliche aufruf:
PathPIDL := ILCreateFromPath(pWideChar(Path));

Zitat:

Call ILFree to release the ITEMIDLIST when you are finished with it.

[MicMic]

"ILCreateFromPath" ist vorhanden aber funktioniert leider nicht.
Ich bekomme auch NIL zurück. Was nicht unbedingt das schlimmste wäre*, aber die Funktion bremst dann alles aus. Das ist dann nicht so toll.

Es geht mir jedenfalls um folgendes.
Ich prüfe mit "ShellFolder.GetAttributesOf" auf die Werte "SFGAO_LINK" und "SFGAO_SHARE".

SFGAO_SHARE nur auf Ordner (ist das richtig?).
SFGAO_LINK kann auch eine Datei sein (z.B. mit MKLINK symdatei.txt richtigedatei.txt). Kann man sogar im besagtem Font-Order (c:\windows\Fonts) erstellen.

So prüfe ich:

Delphi-Quellcode:

function IsLink(aPIDL: PItemIDList): Boolean;
var
  Attrs: DWord;
  ItemIDList: PItemIDList;
  ShellFolder: IShellFolder;
begin
  Result := False;
  if fjLinkOverlay = False then Exit;
  if Succeeded(SHBindToParent(aPidl, IID_IShellFolder, Pointer(ShellFolder), ItemIDList)) then
  begin
    attrs :=  SFGAO_LINK;
    ShellFolder.GetAttributesOf(1, ItemIDList, Attrs);
    if Attrs and SFGAO_LINK <> 0 then result := true else result := false;
  end else result := false;
end;

Also brauche ich ja ein PathToPidl. Und in diesem Font-Ordner geht das nicht.

*Ich will jetzt auch nicht anfangen mit "if path<>'fontordner'" zu arbeiten. Evtl. gibt es ja noch mehrere Windows-Ordner die einem das leben schwer machen. Oder es kommen irgendwann Ordner dazu, die irgendwelche Sonderwünsche beanspruchen und mein PathToPidl (ob meine Funktion oder die "ILCreateFromPath") die Routine bzw. mein Programm ausbremst. Also eine IF-Prüfung wäre nur der richtige weg, wenn ich den Ordner selbst identifizieren könnte, sprich ob's ein normaler Ordner ist oder ein Ordner mit extrawünschen

Der Ordner "Downloaded Program Files" in (c:\Windows) geht z.B. auch nicht, wie ich gerade festgestellt habe. Also beides System-Ordner. Dachte schon die Lösung gefunden zu haben, warum es nicht geht. Jedoch ist "C:\windows\media" auch ein System-Ordner aber hier geht es wieder, ein Pfad+Datei ins PIDL zu bekommen. Also eine IF-Prüfung auf dieses System Attribut kann ich hier auch nicht machen.

[MicMic]

Ich kann zum Glück eine mit MKLINK Symdatei anders prüfen.
Mit dem "FILE_ATTRIBUTE_REPARSE_POINT" kann ich ohne PIDL in solchen Ordnern (die mit PIDL mein Zeug ausbremsen) die Dateien identifizieren.

Trotzdem brauche ich eigentlich auch für SHGetFileInfo ein PIDL. Also das Problem besteht eigentlich weiterhin in diesen Ordnern. Leider bekommt man manchmal ein falsches IconIndex von SHGetFileInfo (ohne PIDL). Hier und da fehlen die Doppelpfeile bei komprimierten Dateien. Selten aber manchmal fehlen die einfach. Dagegen bekomme ich immer das richtige IconIndex (bei komprimierten Dateien) wenn ich SHGetFileInfo mit PIDL nutze.

Also ich muss irgendwie an ein PathToPidl ran. Auch in diesen komischen Ordnern.