Wie Zugriff auf files und ordnern, die ASCII im Namen haben?

[Olli]

Auweia ... dann haben wir es.

Das kann nicht gut gehen. Oben versuchst du mit ANSI-APIs auf einen Namen zuzugreifen, dessen Zeichen jenseits von ÿ liegen ... also über 255. Deshalb bewegst du dich mit ANSI-APIs im Unicodebereich. Das kann ohne Umschaltung der Codepage (wenn überhaupt) nicht gut gehen. Benutze die Unicode-APIs (GetWindowsPathW statt GetWindowsPathA usw ...).

Wenn du dein komplettes Programm auf Unicode trimmen willst, nimm die TNT Unicode Controls.

Übrigens: Ab Windows NT4 sind die Eingaben über Alt+Zahlenblock vierstellig, nämlich Unicode!!!

[Kyro]

verdammt! verdammt verdammt.....

Könntest du mir ein beispiel geben wie ich eine solche datei kopiere?
Bzw. wie kann ich meiner applikation sagen dass er die datei kopieren soll wenn ich nicht einmal unicode zeichen in den code explorer eingeben kann!?

[Olli]

Locker bleiben ... kannst du doch ... mit Typecasts:

Delphi-Quellcode:

var
s: WideString;
s2: WideString;
begin
  s := 'C:\Ottokar'+WideChar(12345)+'.txt';
  s2 := 'D:\bla.txt';
  CopyFileW(@s[1], @s2[1], False {nicht überschreiben});
end;

... ist halt nur umständlich. Aber es geht ... ansonsten immer die Unicode-APIs benutzen in solchen Fällen. Ist in Delphi zwar ätzend, wir arbeiten aber dran

[runger]

Danke Olli,

hab viel dazugelernt!

Rainer

[Kyro]

Danke vorerst einmal, ist aber echt umständlich, dumm dass mir das erst im nachhinein aufgefallen ist!

dieses "Alt+219" Zeichen, welchen wert hätte dieses als widechar(?)

[Olli]

Bitte auch den folgenden Beitrag beachten: http://www.delphipraxis.net/internal...=415625#415625

Zitat von Kyro:

dieses "Alt+219" Zeichen, welchen wert hätte dieses als widechar(?)

Bleibt sich gleich, sollte mit 219 funktionieren, alsoWideChar(219) wenn es denn ein Dezimalwert war. Allerdings kannst du bei den Zeichen unter Wert 256 auch durchaus noch die Syntax mit #255 (oder #$FF) benutzen (zu dem Thema weiterlesen ...).

Also paß' auf, welche Zahlen du castest, ist egal, solange du bei 16bittigen Zahlen bleibst (0..$FFFF), wobei natürlich nicht alle gültige Unicodezeichen sind. Was du wissen mußt, ist daß Windows nach außen nur 2bytige (also 16bittige) Unicodezeichen unterstützt - irgendjemand hier im Forum meinte letztens, daß es ab mind. XP sogar intern Unterstützung für 32bittige Unicodezeichen gibt - konnte ich aber noch nirgends verifizieren, die Native APIs arbeiten noch immer mit 16bittigen Zeichen (außer vielleicht in Win64?!?).

Weiterhin mußt du dir klarmachen, daß die unteren 256 Zeichen im Unicodezeichensatz ja eine 0 im oberen Byte haben, also z.B. hexadezimal $00FF (sie passen also in 1 Byte ohne daß Bits verlorengehen) - dadurch und durch die Tatsache, daß diese ersten 256 Zeichen exakt in den ANSI-Zeichen entsprechen, gibt es bei diesen Zeichen eine Kompatibilität. Hast du also Zeichen wie 'a'..'z', so sind diese eindeutig innerhalb dieses Bereiches und können im Codeeditor normal (als literale Strings) eingetippt werden (der Compiler macht in der EXE literale WideStrings daraus). Alle Zeichenketten aus Ordinalwerten über 255 ($FF) müssen in den mir bekannten Delphiversionen extra durch Aneinanderkettung von WideChar-Casts erzeugt werden. Wenn Delphis Codeeditor Unicode unterstützen würde (vielleicht tun dies neuere Versionen ja doch schon?), dann könntest du diese Zeichen direkt eingeben. Wenn du den Dateinamen allerdings nicht hardcoden mußt, gibt's ja noch die entsprechenden Unicode-APIs zu den ANSI-APIs, welche dir eben ermöglichen direkt die Namen im Unicodeformat zu erhalten.
Unicode wird "a bisserl" unter Win9x unterstützt, allerdings mehr schlecht als recht: MSLU.

@runger: Das freut doch, wenn es noch anderen außer dem Fragesteller etwas bringt

[edit=Admin]Auf Wunsch von Oliver den Link am Anfang dieses Beitrages eingefügt. Mfg, Daniel[/edit]

[Bernhard Geyer]

Vergiss MSLU!

Dies ist nur eine DLL wogegen dein Programm gelinkt wird und das dann intern unter Win9x/ME automatisch die Ansi-Version der API-Funktionen verwendet. Damit wird keine einzige API-Funktion unter Win9x/ME Unicode-Enabled.

Du kommst einfacher ans ziel mit den TNTWare-Controls

[Olli]

Zitat von Bernhard Geyer:

Dies ist nur eine DLL wogegen dein Programm gelinkt wird und das dann intern unter Win9x/ME automatisch die Ansi-Version der API-Funktionen verwendet. Damit wird keine einzige API-Funktion unter Win9x/ME Unicode-Enabled.

... aber man braucht nur noch eine Version seiner Software, nämlich Unicode, schreiben und unterstützen. IMO ein großer Vorteil. Auf NT läuft's ja genau umgekehrt, da werden die Unicode-APIs gewrappt

Wir haben letztens auch herausgefunden, daß viele NT-Funktionen der ADVAPI32.DLL als leere Stubs auf 9x existieren. Ist doch wunderbar, so spart man sich das dynamische Laden von DLLs und Funktionsadressen.

Daß MSLU keinen echten Unicode-Support bringt, wußte ich nicht sicher, dachte es mir aufgrund der Paketgröße aber fast schon.

[Bernhard Geyer]

Zitat von Olli:

Zitat von Bernhard Geyer:

Dies ist nur eine DLL wogegen dein Programm gelinkt wird und das dann intern unter Win9x/ME automatisch die Ansi-Version der API-Funktionen verwendet. Damit wird keine einzige API-Funktion unter Win9x/ME Unicode-Enabled.

... aber man braucht nur noch eine Version seiner Software, nämlich Unicode, schreiben und unterstützen. IMO ein großer Vorteil. Auf NT läuft's ja genau umgekehrt, da werden die Unicode-APIs gewrappt

Na und? Macht die TntWare-Komponenten und das ElPack intern auch. Und du benötigst keine DLL. Und das Elpack kann 100% Unicode-Oberflächen auch unter Win9x/ME was mit MSLU nicht möglich ist.

[Kyro]

Also ich hab mir mal die TNTControls angesehen, bei denen funktioniert zwar das anzeigen von unicode zeichen... bringt mir aber nicht all zu viel.... aber danke für den tipp!

Wie kann ich zum beispiel ein verzeichnis auf der hdd in TNTChecklistbox laden MIT unicode zeichen?
Mit findfirst und TSearchRec kann das ja nicht klappen nachdem die ja die namen als string ausgeben!?

ebenso das kopieren mit filestream ist von dateien die im namen unicode zeichen enthalten nicht möglich, oder?
Mit CopyFileW klappt das kopieren generell zwar mit diesen dateien, kann aber zum beispiel kein resuming oder statusanzeige ermöglichen.

Danke für eure Hilfe!!!!