Alternative zur Funktion FileGetAttr?

[hoika]

Hallo,
schreib dir deine eigene Methode als Wrapper, also in etwa so:

Delphi-Quellcode:

function MyFileGetAttr(AFileName ...);
begin
{$WARNINGS OFF}
  Result:= FileGetAttr(AFileName);
{$WARNINGS ON}

Somit musst das Warning (heisst das nicht sogar PLATFORM ?)
nicht an tausend Stellen machen und musst beim Umstieg
auf eine neuere Version nur eine Stelle ändern.

Wenn du unter Windows bleibst, könntest die die Plattform-Warnungen natürlich auch global ausschalten.

[Uwe Raabe]

Zitat von Andreas L.:

Das gibt es leider in Delphi 2009 noch nicht.

Zitat von hoika:

Wenn du unter Windows bleibst, könntest die die Plattform-Warnungen natürlich auch global ausschalten.

Für welche Plattformen kann man nochmal unter Delphi 2009 entwickeln

[mjustin]

Zitat von Uwe Raabe:

Zitat von Andreas L.:

Das gibt es leider in Delphi 2009 noch nicht.

Zitat von hoika:

Wenn du unter Windows bleibst, könntest die die Plattform-Warnungen natürlich auch global ausschalten.

Für welche Plattformen kann man nochmal unter Delphi 2009 entwickeln

Vielleicht sind diese Warnungen eine Folge der .Net 'Bemühungen' in Delphi? Frage an die Delphi-Historiker

Hauptsache, das Ausschalten funktioniert - die Warnungen erscheinen bei mir standardmäßig auch und nach dem Abschalten nicht mehr.

[Delphi.Narium]

Diese Meldungen bekommt man mit Delphi 7 auch schon, damit man ggfls. kompatibel mit Kylix für Unix programmieren kann.

Durch die Delphisoucen von Delphi 7 ziehen sich solche Konstrukte:

Delphi-Quellcode:

uses
{$IFDEF MSWINDOWS}
  Windows,
{$ENDIF}
{$IFDEF LINUX}
  Types,
{$ENDIF}
  ...

Warum sollte man das bei Delphi 2009 alles wieder rausgeschmissen haben?

(jaja: langlangistsher )

[Rollo62]

Das bestätigt mich in meiner Annahme das Delphi seiner Zeit schon immer weit vorraus war

[dummzeuch]

Die Platform-Warnungen wurden mit Delphi 6 (wegen Kylix 1) eingeführt, zusammen mit:

• SYMBOL_DEPRECATED
• SYMBOL_LIBRARY
• SYMBOL_PLATFORM
• UNIT_LIBRARY
• UNIT_PLATFORM
• UNIT_DEPRECATED

[Assarbad]

Also es gibt noch zwei offizielle direkt windowsspezifische Versionen. Einmal mit GetFileAttributes und einmal mit FindFirstFile/FindNextFile. Beide sind Win32-Funktionen.

Wenn du also bspw. ohnehin Dateien listest, bist du mit den letzten beiden am besten bedient. Bei GetFileAttributes wird es langsam, sobald man die Attribute vieler Dateien auflistet. Der Grund ist einfach: GetFileAttributes benutzt den Namen um zur Datei zu kommen. Bei FindFirstFile/FindNextFile hingegen wird das Elternverzeichnis bemüht und die Attribute sind ohnehin eigentlich immer dabei (siehe NtQueryDirectoryFile). Kommt halt auf die Ziele an.