Unicode Compiler Option

[Lossy eX]

Du musst für die Unicode Unterstützung auch wirklich komplett Unicode verwenden. Wenn du auch nur eine einzige Stelle hast an denen du kein Unicode benutzt, dann bringt das nix.

Zitat von EWeiss:

Zitat von mkinzler:

Versuchs es mal mit PWideChar

So wie lossy mir das erklärt hat würde das nichts bringen
Wenn die Applikation einen string schickt dann ist der Unicode Part innerhalb des strings schon gebrochen
was bedeutet das er nicht mehr UniCode fähig ist.
Also muss ihn auf jedenfall selbst wieder ins Unicodeformat konvertieren
Das funktioniert ja auch ohne probleme.

Um da etwas ins Detail zu gehen. Wenn du mit FindFirst und FindNext arbeitest hast du schon verlohren. Denn dann bekommst du nur Strings. Und diese Strings sind lokalisiert. Also ANSI mit einer Codepage. Alle Zeichen die nicht in der Codepage enthalten sind nicht vorhanden bzw ein Fragezeichen. Anstelle dieser Funktionen müsstest du dann FindFirstW und FindNextW aus der Windows Api benutzen. Dann bekommst du echte WideStrings und die kannst du dann auch als pWideChar an die TextSuite übergeben (die passende WideMethode versteht sich). Aber du musst dann wirklich überall mit WideStrings arbeiten.

Alternativ zu WideStrings würden auch UTF8 kodierte Strings gehen. Die würden beim Zuweisen auf Strings nicht beschädigt werden. Aber das Kodieren und Dekodieren ist aufwändiger. Bzw die Wide Funktionen der Win API arbeiten normal über WideStrings.

Wenn die Zeichen nie vorgelegen haben, dann werden sie auch nie wieder reingerechnet werden können. Und dann ist es egal ob du das selber machst oder nicht. Das geht nicht. Du darfst wirklich strikt nur mit WideStrings arbeiten. Ansonst hast du evtl. ein paar Unicodezeichen. Aber auch nur die die sich innerhalb der Codepage befinden.

Da String und WideString Zuweisungskompatibel sind geht es leider sehr sehr schnell, dass man sich vorhandene WideStrings zerschießt.