Bislang habe ich diesen Ordner über CSIDL_PERSONAL abgefragt.
Nach einem Problem nun auch testweise sowohl über TPath.GetDocumentsPath als auch FOLDERID_Documents.
https://docwiki.embarcadero.com/RADS...rget_Platforms
https://learn.microsoft.com/de-de/wi.../knownfolderid

Ich habe nun ein System, auf dem alle 3 Varianten (die möglicherweise identisch sind) nichts zurückliefern.

Auf dem entsprechenden System hat der Benutzer seinen Ordner "Dokumente" auf ein zweites Laufwerk verschoben gehabt (über die WIndowsfunktion).

Ich dachte, dass man über die API-Aufrufe auch diese verschobenen Ordner zurückgeliefert bekommt.

Hat jemand ähnliche Probleme und wie greift Ihr auf den entsprechenden Ordner drauf zu?

Wäre dann nicht eher FOLDERID_Documents bzw. TPath.GetDocumentsPath der bessere Ansatz?

Sorry - habe die falschen Werte kopiert.
Ich nutze
CSIDL_PERSONAL // TPath.GetDocumentsPath // FOLDERID_Documents

aber da kommt immer '' zurück.

Ich habe nun selber auf einem Testrechner den Ordner verschoben. Da funktioniert alles korrekt.
Nur bei einem Kunden leider nicht

Ein ähnliches Phänomen hatte ich auch mal bei einem Kunden. Die hatten damals neue Windows-Server installiert und irgendwelche Registry-Einträge der alten Windows-Server drüber gebügelt. Das hat vorne und hinten nicht funktioniert. Ggf. kann dein Kunde die Umleitung nochmal aufheben und neu einrichten?

Auf dem Rechner haben wir jetzt den Ordner in der Registry unter "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Curr entVersion\Explorer\User Shell Folders\Personal" manuell mit vollständigem Pfad eingetragen.
Das hat dann funktioniert. Bis man den Ordner testweise erneut verschoben hat. Dann taucht das Problem wieder.
Temporär ist das Problem gelöst.

Es gibt Dinge, die ich als gegeben voraussetze und darunter fiel bislang auch die Rückgabe dieses Ordners.
Ich bin nicht einmal ansatzweise auf die Idee gekommen, dass ich einen leeren String erhalte.