AssignFile und WideString Dateiname

[martinf16]

Hallo,
ich wollte einen Code zum Öffnen einer Datei auf WideStrings umstellen. Der wichtigste Ausschnitt des Codes ist folgender:

Delphi-Quellcode:

var
  FileName: WideString;
  F: File;
begin
  {...}
  AssignFile(F, FileName);    
  Reset(F, 1); 
  BlockRead(....
  {...}
end;

Der Code funktioniert super bis zu dem Moment wo andere als ANSI-Zeichen im FileName vorkommen. Offenbar kann AssignFile nicht mit diesen Zeichen umgehen?! Wie kann ich das nun aber lösen?
Ich habe mich bereits überall umgesehen, den einzigen Lösungsansatz, den ich bisher fand, war den Dateinamen in seinen kurzen Dateinamen (8.3) umzuwandeln, der kein Unicode enthalten soll. Diese Lösung finde ich aber nicht sehr elegant, das muss doch einfacher gehen. Also sowas wie WideAssignFile oder ähnliches. In den TNT's habe ich mich auch schon umgeschaut aber auch nichts gefunden.
Vielen Dank schonmal!

[sx2008]

Bitte gib' doch deine Delphi Version an (im Profil); ist wichtig für die Beurteilung der Frage.
Der Datentyp "File" ist übrigens völlig veraltet, man sollte stattdessen Streams benützen.
Wenn du kein Delphi 2009 oder neuer hast, dann fehlt dir die Unicode Unterstützung und
TFileStream.Create() nimmt nur einen normalen Ansi-String entgegen.

Trotzdem muss man dann noch nicht aufgeben, denn man kann sich mit der Windows-API
Funktion CreateFileW() ein Handle erzeugen und dieses Handle einem THandleStream Objekt übergeben.

Da man der Funktion CreateFileW() sehr viele Parameter übergeben muss, ist es empfehlenswert,
sich eine Klasse von THandleStream abzuleiten (Namensvorschlag TFileStreamW).

[p80286]

Zitat von sx2008:

...Der Datentyp "File" ist übrigens völlig veraltet, man sollte stattdessen Streams benützen....

Auch wenn ich pers. in der Zwischenzeit Streams nutze (sind meist genauso schnell wie "files") würde mich trotzdem interessieren was an File veraltet sein soll.

Nur weil es "File" schon zu seligen Pascalzeiten gab und er somit relativ alt ist, ist er noch längst nicht veraltet. Daß er mit WideStrings als Dateinamen nicht umgehen kann, würde ich nicht als veraltet, sondern als inkompatibel oder "unfähig" bezeichnen. Aber die grundsätzliche Funktionalität ist heute immer noch gewährleistet.
(Den wahrhaftig mickkrigen Puffer bei Textfile lassen wir einmal aussen vor).

Gruß
K-H

[himitsu]

Vorallem das "File" einen internen Puffer verwendet, wobei Windows schon einen einsetzt (die WindowsFileCache) und was am Schlimmsten ist, daß dieser Puffer auch noch mit seinen 128 Byte völlig "schwachsinnig" dimensioniert ist.

Ansonsten ist es einfach nicht so schön OOP.

[gammatester]

Zitat von himitsu:

Vorallem das "File" einen internen Puffer verwendet, wobei Windows schon einen einsetzt (die WindowsFileCache) und was am Schlimmsten ist, daß dieser Puffer auch noch mit seinen 128 Byte völlig "schwachsinnig" dimensioniert ist.

Ansonsten ist es einfach nicht so schön OOP. :stupid:

Was für einen "internen Puffer" meinst Du? Ich sehe keinen in der Definition.

Delphi-Quellcode:

type
{ Typed-file and untyped-file record }

  TFileRec = packed record (* must match the size the compiler generates: 592 bytes *)
    Handle: Integer;
    Mode: Word;
    Flags: Word;
    case Byte of
      0: (RecSize: Cardinal);   //  files of record
      1: (BufSize: Cardinal;    //  text files
          BufPos: Cardinal;
          BufEnd: Cardinal;
          BufPtr: PAnsiChar;
          OpenFunc: Pointer;
          InOutFunc: Pointer;
          FlushFunc: Pointer;
          CloseFunc: Pointer;
          UserData: array[1..32] of Byte;
          {$IFNDEF UNICODE}
          Name: array[0..259] of AnsiChar;
          {$ELSE}
          Name: array[0..259] of WideChar;
          {$ENDIF}
      );
  end;

Aber vielleicht meinst Du ja gar nicht file sondern text, das mit read/ln, write/ln bearbeitet wird. Aber da kannst Du, wenn Du 128 Bytes als schwachsinning ansiehst, die Größe mit SetTextBuf ändern.

[himitsu]

wo? > .BufPtr

Abgesehn davon kann AssignFile ab D2009 zwar Unicode-Dateinamen,
aber Write/WriteLn machen aus den ihnen übergebenen UnicodeString nette Ansi-Strings.


Ich sagte nicht, daß AssignFile und Co. extrem schlecht sind ... für kleine Dinge nutze selbst ich ieses manchmal, aber bei größeren Dateien machen sich die "neueren" OOP-Funktionen/Klassen schon besser.

Und im Normalfall braucht man programmintern eigentlich keinen Puffer, da der ja standardmäßig schon seitens Windows vorhanden ist.

[martinf16]

Okay, ich habe mein Profil aktualisiert. Ich nutze den Turbo Explorer.
Ich habe für die Unicode Unterstützung bislang die TNT Komponenten genutzt und natürlich diverse angepasserte Codes aus dem Internet.

[himitsu]

In den TNTs sollte eine TWideStringList und ein TWideFileStream vorhanden sein,
genau wegen der fehlenden Unicodeunterstützung seitens deines Delphis gibt es diese Klassen.

AssignFile ist nunmal nativ nur ANSI.

Du müßtest dir also einen neuen Unicopde-FileRec erstellen, ein eigenes AssignFile, welches den UnicodeNamen entgegennimmt und alle (nötigen) Datei-Öffnen-Prozedure, wie Reset, Rewrite und Append, denn erst darin wird die Datei wirklich geöffnet.

[gammatester]

Zitat von himitsu:

wo? > .BufPtr

Wie man leicht sieht, gilt das nur für Textfiles und nicht für file bzw. file of <type>.

[himitsu]

Stimmt, grad nochmal nachgesehn ... mir war aber so, als hätte ich dort auch mal 'nen Puffer gesehn

Aber mal anderstum: Was spricht gegen die neuen OOP-Varianten?