japanische Sprache

[roderich]

Ich habe folgendes Problem:

Mein Programm ist mehrsprachig ausgelegt. Es funktionieren auch die europäischen Sprachen wie deutsch, englisch, spanisch, etc. problemlos. Zur Laufzeit werden den Controls Texte aus einer Sprachdatei zugewiesen, je nach Klasse die properties Caption, Hint, Text usw.

Nun habe ich japanisch dazugenommen, ein Japaner hat Texte übersetzt. Auf einem japanischen Windows sollten dann die Texte entsprechend sein. Nun habe ich aber das Problem, daß es bei einigen Controls klappt, bei anderen nicht. Z.B. klappt es bei TMenuItem, TButton oder TRadioButton. Es klappt nicht bei TGroupBox, TLabel oder TBitButton.

Was mir aufgefallen ist, daß die japanischen Texte in UniCode (2 Byte / Zeichen) gespeichert sind. Offensichtlich kommen einige Controls damit klar, andere nicht. Seltsamerweise ist TBitButton von TButton abgeleitet und verhält sich anders.

Jemand eine Idee ?!?

Roderich

[tommie-lie]

Unicode funktioniert generell nicht unter Win95 und 98 (bei ME weiß ich's nicht mehr). Bei den Systemen muss man sich den Microsoft Unicode Mapper runterladen. Deine Strings müssen alle als WideString deklariert sein, damit pro Zeichen 2 Byte benutzt werden.

Ansonsten hat Mike Lischke irgendwo mal Unicode-Komponenten für Delphi geschrieben. Die könntest du alternativ zu den Borland-Komponenten verwenden, ob die aber das Problem des fehlenden Mappers lösen, weiß ich nicht.

[roderich]

hi tommie-lie,

schon mal vielen Dank für die Hilfe. Ich werd's mal mit WideString probieren. Auf dem Japaner-Rechner läuft Windows XP.
Komisch ist nur trotzdem, daß einige Controls ihre Caption richtig setzen - als ob sie in SetCaption erkennen, daß der String einen UniCode-String darstellt. In NotePad sehe ich in den Strings immer abwechselnd eine Art Lo-Character und einen Hi-Character.

erst mal vielen Dank
Roderich

[tommie-lie]

Zitat:

Zitat von roderich

Komisch ist nur trotzdem, daß einige Controls ihre Caption richtig setzen - als ob sie in SetCaption erkennen, daß der String einen UniCode-String darstellt.

Das finde ich auch seltsam. Ich weiß zwar nicht, wie du deine Sprachdateien einliest, aber wenn du es beispielsweise mit 'nem Filestream machst und in einen "normalen" String einliest, sollte das eigentlich sowieso nix werden...

Zitat:

In NotePad sehe ich in den Strings immer abwechselnd eine Art Lo-Character und einen Hi-Character.

Jupp, weil für das deutsche Notepad ein Zeichen ein Byte lang ist. Da bei Unicode es immer zwei Byte sind, zeigt er jedes getrennt an. In einem Hexeditor solltest du erkennen, daß bei Zeichen, die noch in die ASCII/ANSI-Tabelle passen, das zweite Byte immer 00h ist und das erste Byte den ANSI-Wert des Zeichens hat. Das ändert sich dann bei den Zeichen, die in ASCII/ANSI nicht mehr darstellbar sind.

[roderich]

hi tommie-lie,

ich lese die Sprachdateien ganz einfach ein mit TIniDatei.ReadString, d.h. in einen normalen 1 Byte-pro-Zeichen-String. Trotzdem funktioniert es auf dem Japaner-PC komischerweise bei einigen Controls.
Wie gesagt scheinen einige Controls die Intelligenz zu haben, einen UniCode-String in einem "normalen" String zu erkennen.

Roderich

[tommie-lie]

Zitat:

Zitat von roderich

Trotzdem funktioniert es auf dem Japaner-PC komischerweise bei einigen Controls.

Wie sieht es denn bei den Controls aus, bei denen es nicht funktioniert? Einfach nichts, oder nur der erste Buchstabe oder was ganz anderes?

Zitat:

Wie gesagt scheinen einige Controls die Intelligenz zu haben, einen UniCode-String in einem "normalen" String zu erkennen.

Hmm...
Bei C-Strings wie sie Wndows verwendet markiert ein Nullbyte ja das Stringende. Da bei Unicode im westlichen Raum das ja jedes zweite byte ist, ist bei Unicodestrings ein Doppel-Nullbyte der Terminator, evtl erkennen das einige. Aber theoretisch müssten es alle erkennen, schließlich sollte Windows da nicht großartig unterscheiden, die VCL greift ja auch nur auf die Windows-Funktionen zurück...

[Luckie]

Zitat:

Zitat von roderich

ich lese die Sprachdateien ganz einfach ein mit TIniDatei.ReadString, d.h. in einen normalen 1 Byte-pro-Zeichen-String.

Dann sollte das aber nicht gehen. Du liest einen 2 Byte Zeichensatzstring in ein 1 Byte Zeichensatzstring ein. Und was passiert mit dem zweiten Byte? Bei den westlichen Sprachen mit Lateinischenbuchstaben mag das ja noch gehen, da das zweite Byte #0 ist und keine Informationen trägt, aber was ist bei anderen Sprachen, wo das zweite Byte auch Informationen beinhaltet?
Ich würde bei dir im Moment auf Zufall tippen.

[roderich]

hi tommie-lie,

bei den Controls, wo es nicht funktioniert (z.B. TBitButton) wird der Text so dargestellt, als ob es ein normaler String wäre. Also beispielweise ƒŒƒCƒAƒEƒg (= 10 Zeichen Schrott), wo eigentlich 5 japanische Zeichen stehen sollten. Man erkennt deutlich das jeweilige Lo-Char (ƒ). Die Caption-Zuweisung bei TButtons, wo es klappt, ist haargenau die gleiche; grob gesagt aButton.Caption := aIniFile.ReadString(blabla, blabla).

Wenn man googelt, findet man Aussagen, daß Delphi kaum UniCode-Unterstützung bietet und man daher Komponenten verwenden muß, deren Caption ein WideString ist und deren TextOut speziell angepasst ist. Nur leider hat mein Hauptprogramm ca. 250.000 Zeilen und ca. 100 Formulare mit zusammen sowiesoviel Komponenten :-( Habe keine Lust, die alle zu ersetzen.


Dir jedenfalls 1000 Dank für die Hilfe !

viele Grüße
Roderich

[Chewie]

250.000 Zeilen :shock: Hast du ein Betriebsystem geschrieben?

[roderich]

Zitat:

250.000 Zeilen Hast du ein Betriebsystem geschrieben?

so ungefähr.....
nee, das Projekt läuft schon 3 Jahre. Aber eigener Code sind es vielleicht 200.000 Zeilen, der Rest sind Komponenten.

Luckie, ich glaube nicht an Zufall. Ich habe einige Screenshots bekommen, und da sieht man, daß z.B. TMenuItems immer funktionieren und TBitButtons nie. Es muß daran liegen, daß einige Komponenten ihre eigene nicht-unicode-fähige Draw-Routine haben, während andere Komponenten auf ExtTextOutW o.ä. aus der API zugreifen. Dieses ExtTextOutW ist dann wohl so schlau, daß es UniCode-Strings richtig ausgibt.

Roderich

[Phoenix]

Der erste Linux-Kernel waren nicht mehr als 4 Kb Quelltext, das kann es also nicht sein :)

[Luckie]

Zitat:

Zitat von roderich

Dieses ExtTextOutW ist dann wohl so schlau, daß es UniCode-Strings richtig ausgibt.

Wenn Microsoft konsequent war, dann sollte man an Hand des Funtionsnames ...W davon ausgehen, dass diese Funktion mit UniCode (WideChar) Zeichensätzen umgehen kann. Und zwar nicht weil sie "schlau" ist, sondern weil sie dafür geschrieben wurden.

[Gast]

Unicode Controls!

http://home.ccci.org/wolbrink/tnt/de...e_controls.htm

Nachtrag:

Zitat:

Features*
Unicode enabled Delphi/C++Builder object inspector!
Unicode enabled hints.
Unicode enabled actions.
Works well with any IME.

Supports Unicode-only locales.
Correctly streams WideString properties on forms.

* Unicode features are only enabled on Windows NT/2000/XP.

[roderich]

hi Luckie,

hast Recht, im Zusammenhang mit Microsoft verbietet sich das Wort "schlau" von selbst.

Daß ExtTextOutW mit WideChars umgehen kann, ist klar, aber was mich wundert, daß es funktioniert, obwohl der Caption ja ein normaler String zugewiesen war.
Das mit dem ExtTextOutW ist nur so ne Vermutung, bin gerade dabei, den Source von TButton zu verstehen.....

Roderich

[Luckie]

Zitat:

Zitat von Luckie

Und zwar nicht weil sie "schlau" ist, sondern weil sie dafür geschrieben wurden.

Du hast mich falsch verstanden. das war so gemeint, dass ...W Funktionen von Microsoft extra für UniCode entwickelt wurden. Das hat nichts mit den Fähigkeiten der Programmierer von MS zu tun.

[roderich]

hi Assarbad,

danke für den Link. Aber wenn ich alle meine Standard-Komponenten durch UniCode-fähige ersetzen muß, habe ich verloren (s.o.)....

Also wo man sich umhört, jeder sagt, daß UniCode ohne WideString gar nicht funktioniert. Borland scheint seine VCL auch auf die ...A API-Routinen hinprogrammiert zu haben und nicht auf die ...W Routinen.
Nur kapier ich nicht, warum einige der Komponenten damit keine Probleme haben, einen normalen String als UniCode auszugeben !?!

Roderich (am verzweifeln)

[Gast]

Zitat:

Daß ExtTextOutW mit WideChars umgehen kann, ist klar, aber was mich wundert, daß es funktioniert, obwohl der Caption ja ein normaler String zugewiesen war.
Das mit dem ExtTextOutW ist nur so ne Vermutung, bin gerade dabei, den Source von TButton zu verstehen.....

Bist du sicher mit "normaler String". Bei Delphi weiss man das oft nicht, da der Compiler sehr oft Typecasts einwirft, wo du sie nie vermuten wuerdest. Deshalb waere ich mit der Aussage vorsichtig. Das siehste erst im Disassembler :)

Ich habe die Erfahrung gemacht, dass bei Ansi-Apps auch noch die Locale stimmen muss. ZB sehe ich auf meinem Rechner daheim (W2K) keine kyrillischen Zeichen im TurboNavigator (Locale = Deutsch) ... bei dem Server an welchem ich grad sitze, aber schon (Locale = Russisch).

TButton uebernimmt nur intern die ganze Nachrichtenverarbeitung. Er verhaelt sich aber wie jeder normale Button. Und Buttons (und auch andere Basiscontrols) haben IMMER die gleiche Nachricht (WM_SETTEXT) fuer das setzen von Unicode UND Ansi-Strings ... das koennte die Loesung des Raetsels sein.