Probleme mit Codepage(?)

[freejay]

Hallo,

ich habe eine Anwendung, die polnische Texte darstellt, die von einer mySQL-Datenbank kommen. Um die Texte korrekt anzuzeigen, habe ich in der Datenbank alles auf cp1250 eingestellt, meine DB-Zugriffskomponente (myDAC) auf cp1250 und beim Font in allen Controls Font.Charset = EASTEUROPE_CHARSET (Integerwert 238) gestellt, was (angeblich) das Equivalent zu cp1250 ist.

Das hat letzte Woche auch funktioniert und funktioniert auch immer noch auf dem Citrix-Server, wo das Programm produktiv läuft. Aber auf meinem Rechner funktioniert es seid heut nicht mehr:

Ich kann für Font.Charset alles einstellen, was ich will, die Zeichen werden immer mit DEFAULT_CHARSET angezeigt, also falsch!

Kann mir irgendjemand helfen?

Gruß

Freejay

[Bernhard Geyer]

Vergiss Charset/Codepages! Du wirst keine vernünftige 100%ige Lösung damit hin bekommen. Stell alles auf Unicode/UTF8 um und alles wird gut.
Dazu nimmst du entweder D2009 oder Elpack oder TNTWare für die Anzeige.

[freejay]

Hallo Berhard,

Danke für Deine Antwort. Unicode ist mittel- bis langfristig auch mein Ziel. Im Moment hängen jedoch viel zu viele andere Dinge daran, so dass ein Umstieg zeitlich gerade nicht machbar ist.

Fakt ist, dass ich eine Lösung hatte, die gleiche Anwendung (nicht etwa neu kompilliert!) läßt sich nur heute nicht mehr durch Codepage-Vorgaben beeindrucken und bleibt stur bei (ich nehme mal an) westeuropäisch.

Hat jemand eine Idee dazu?

Gruß

Freejay

[Bernhard Geyer]

Zitat von freejay:

Danke für Deine Antwort. Unicode ist mittel- bis langfristig auch mein Ziel. Im Moment hängen jedoch viel zu viele andere Dinge daran, so dass ein Umstieg zeitlich gerade nicht machbar ist.

Weist du denn wie aufwändig ein Umstieg ist? Vor allem ein TNTWare-Umbau ist relativ einfach, da alle TNT-Controls fast zu 100% Kompatible mit den normalen Controls ist. Und dann noch mit DevArt (ich denke du meinst mit MySQL den alten Namen der Zugriffskompos) kombiniert dürfte nach umstellung von String -> Widestring nicht zu viel übrig bleiben.

[freejay]

Das ist alles etwas komplizierter als gedacht, da ich die Daten selbst auch in die DB einspielen und diese wiederum von einer ganz anderen Sybase-Datenbank kommen und die, weil dort bestimmt 30 zum Teil uralte produktionsrelevante Anwendungen daran hängen, auf absehbare Zeit nicht auf Unicode umgestellt werden kann etc. etc..

[Bernhard Geyer]

Trotzdem ist es vernünftiger deine Anwendung + MySQL-Anbindung Full-Unicode-Fähig zu gestalten und die Koppelfunktionen zur Legacy-Anwendung entsprechende zu behandeln anstatt in der kompletten Anwendung mit der "Lösung" Codepages zu arbeiten.

[freejay]

Da hast Du schon recht und das ist ja auch geplant (s.o.). Aber die Anwendung muss jetzt morgen in der momentanen Version raus und da hätte ich diese Sache gern vorher noch geklärt.

Ich habe mich halt bisher nicht mit internationalen Notwendigkeiten befassen müssen, da meine Software bisher nur im deutschsprachigen Raum benutzt wurde. Und da eine schnelle Lösung für die Polen her musste, konnte ich nicht das ganze System umkrempeln. Dafür bräuchte ich vermutlich ein Vierteljahr Zeit (ja, das Projekt ist sehr umfangreich, da von diesen Daten x Anwendungen abhängen und die Datenbank aus mindesten 10 verschiedenen Quellen gefüllt wird usw.).

Na dann hat also keiner eine Antwort auf meine ursprüngliche Frage. Muss ich halt erstmal damit leben.

Trotzdem Danke.

[Bernhard Geyer]

Wenn die Lösung nur unter einem polnischen System Polnisch unterstützen muß (und nicht auf polnischen System Deutsch und umgekehrt), so brauchst du gar nix machen. Font.Charset auf DEFAULT_CHARSET stehen lassen und nur schauen das die DB mit Unicode läuft und gut ist. Diese Art von Internationalisierung unterstützt Delphi schon sehr lange.