Einzelnen Beitrag anzeigen

Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.157 Beiträge
 
Delphi 12 Athens
 
#8

AW: Verständnisfrage zu fdoForceFileSystem

  Alt 1. Jan 2020, 22:36
Es kommt drauf an.
Ordnerauswahl für einen Schreibzugriff ausschließlich auf lokale Pfade, da könnte fdoForceFileSystem nicht schaden. (Lesen geht fast immer, aber schreiben eventuell nicht ... siehe HTTP)

Ich persönlich hab diese Option noch nie benutzt und es gab bissher auch noch keine Probleme.

ofPathMustExist aktiviere ich eigentlich immer. (neue Verzeichnisse müssen dann vorher explizit erstellt werden, was in dem Dialog ja auch geht)
Für Öffnendialoge ist ofFileMustExist immer aktiv, weil die Datei muß ja sowieso existieren und der Fehler wird sofort gemeldet.
Bei Speicherndialogen nutze ich machmal ofOverwritePrompt, damit der Nutzer nicht irgendwas "ausversehn" bzw. unbemerkt überschreibt. (es sei denn Überschreiben ist das Standardverhalten)

ofNoTestFileCreate ist auch nahezu immer gesetzt, denn muß man bei WriteOnly-Laufwerken beachten, was z.B. auch auf ein Netzlaufwerk zum NAS zutrifft oder ganz speziell auf WORM, welche eine Versionierung vornimmen.
(bei ofNoTestFileCreate erstellt und löscht der Dialog die Datei einmal, was blöd endet, wenn sich die Datei nicht mehr löschen oder verändern lässt
und auch im Log tauchen dann unnötige Zugriffe auf)


Wie gesagt, meistens wird fdoForceFileSystem nicht benötigt. Es wäre auch etwas hinderlich, wenn man Netzwerkpfade erlauben möchte.
MSDN-Library durchsuchenCreateFile, TFileStream, LoadFromFile usw. kommen mit sehr ... sehr viel zurecht, wie UNC und sogar FTP, HTTP usw. wurde von Microsoft implementiert.

Ich weiß nicht mehr wie, aber man kann in diesem Dialog auch Drucker und Scanner auflisten lassen.
Beim Speichern einer Datei würde es mit soeinem Pfad eventuell ein paar Probleme geben.

Falls du mit IShellItem und dessen API und Stream-Zugriffen arbeitest, dann kann praktisch alles verwendet werden.
.FileName -> .ShellItem
.Files -> .ShellItems

Aber standardmäßig listet dieser Dialog sowieso nur Dinge auf, zu denen es einen schönen Pfad im Dateisystem gibt, welcher sich über .FileName auslesen und mit den meisten FileAPIs verwenden lässt.
Deswegen bemerkst du bei deinen Tests wohl auch keinen Unterschied.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu ( 1. Jan 2020 um 22:45 Uhr)
  Mit Zitat antworten Zitat