Chinesisch/Russisch in Delphi nur mit Bordmitteln?

[Olli]

Zum verlinkten Blog-Eintrag:
Tja, was soll man dazu sagen. Wiedermal ist die (Rückwärts-)Kompatibilität die Begründung etwas zu vermeiden ...

Dieses Problem hätte lange gelöst sein können, wenn man global Präprozessor-Defines in den Projektoptionen mitgeben könnte. Damit könnte man Unicode- und Ansi-VCL sauber getrennt halten und würde dennoch all jene zufriedenstellen, die berechtigtes Interesse an einer Unicode-Version haben. Offensichtlich ist Borland selbst nicht international genug um die Dimension dieser Fehlentscheidung zu erkennen.
Delphi 2, das erste 32-Bit-Delphi überhaupt, wurde im Jahr 1996 veröffentlicht. Zu diesem Zeitpunkt gab es schon 4 (? - bin nicht sicher) Jahre lang NT 3.51 welches ebenfalls unicode-fähig war und in ebenjenem Jahr 1996 kam Windows NT 4.0 heraus. Es gibt also keine Entschuldigung, daß in Delphi 2006 - 10 Jahre danach - noch immer kein Unicode-Support enthalten ist. Und Hand auf's Herz: es gab zwischenzeitlich auch andere Änderungen, die die Kompatibilität bedroht haben ... auf der anderen Seite sind garnicht alle Komponenten empfindlich für eine Änderung der VCL von Ansi nach Unicode. Es gibt schließlich Komponenten die ganz simpel auf keine der Funktionen zugreifen, welche in Ansi- und Unicode-Variante existieren.

Alles etwas seltsam und - wenn man sich die Jahreszahlen anschaut - leicht unbegreiflich, wieso Unicode nicht von Anfang an voll unterstützt wurde.

[himitsu]

Was mit beim Thema Unicode noch stört, ist daß intern WideStrings auf OLE-Strings auf umgebogen werden.
Warum kann Borland da nicht auch, wie bei den AnsiStrings, das "eigene" Format benutzen (keine OLE32.dll mehr nötig und, neben anderen Vorteilen, vorallem endlich mit Referenzzählung..)

[merlin17]

Zitat:

Tja, was soll man dazu sagen. Wiedermal ist die (Rückwärts-)Kompatibilität die Begründung etwas zu vermeiden ...

und wir bei Nevrona kriegen damit auch noch "Prügel", weil unsere Win32-ReportEngine, basierend auf VCL, nicht Unicode-fähig
ist und wird (ich meine Win32, nicht .net, hier ist UniCode auch bei Rave enthalten!)


:-) thomas, TeamNevrona

[himitsu]

Ach, am Besten war ich vorrige Woche über die RessourceStrings gestolpert ... OK im Programm (Quellcode) kann man da zwar nur ANSI angeben, aber in den Resourcen ist der String ja als Unicode gespeichert ... also dachte ich ist ja geil, ein String der nur gespeichert wird, wenn er auch verwendet wird (anders, wenn man Resourcen per {$R...} reinläd, welche ja immer eingebunden werden, egal ob man das $R in eine nichtverwendete Procedur verschachtelt hat) und dazunoch die möglichkeit über einfach Technicken nachträglich andere Sprachen drüberzuladen (per DLL sogar abhängig von der in Windows verwendeten Sprache), aber nein, der wird dann auch noch als ANSI wieder ausgelesen und es gibt wohl keine Möglichkeit ihn selber per LoadStringW auszulesen :cry:

[clancy38]

Also, erstmal danke für alle antworten.

Das Problem ist jetzt soweit gelöst:
Die Excel-Tabelle wird nach Word exportiert, dort kann sie mit (im Gegensatz zu Excel)
als "Nur-Text" gespeichert werden bei gleichzeitiger Auswahl eines Zeichensatzes.

Mit dem Editor ist sie dann zwar nicht mehr lesbar, verändert man dann in Delphi aber bei Auswahl
von chinesischer Sprache den Wert für Charset, hat im Betriebssystem die Unterstützung für
ostasiatische Sprachen installiert, dann werden alle chinesischen Schriftzeichen so wie in der
Exceltabelle vollkommen korrekt angezeigt.

Das klappt u.a. genauso mit Russisch und Japanisch

@Jus
Hmm, wenn du einen Chef hast, der sogar notwendige Updates für Delphi komplett ablehnt und sog.
Fremdkomponenten als Werk des Teufels (hat er ja nicht selber geschrieben) bezeichnet, was willste da
machen?

Trotzdem nochmals Danke an alle, die mir Tips hier reingeschrieben haben.