Sonderzeichen in TEdits (Charset?)

[uligerhardt]

Wir haben eine ältere Prä-Unicode-Anwendung, die mittlerweile auf D2007 portiert ist. In dieser kann der Anwender auswählen, welches Charset für TEdits verwendet wird. Wenn der Benutzer (auf einem deutschen System) z.B. Russisch auswählt und dann äöüÄÖÜß eintippt, sieht das im Edit wie im Anhang aus - soweit so gut. Jetzt versuche ich dieses Verhalten in einer "jungfräulichen" D2007-VCL-Anwendung nachzuvollziehen (Form1 mit einem Edit1 drauf) und kriege es nicht hin. Offensichtlich reicht ein

Delphi-Quellcode:

  Edit1.Font.Charset := RUSSIAN_CHARSET;

nicht aus. Habt ihr eine Idee, was ich da vergessen habe? Im Quelltext der Anwendung, wo es funktioniert, springt mir leider nichts einschlägiges ins Auge.

[shmia]

Bei meinem Delphi 5 funktioniert das auf Abhieb nur durch Umstellen von Font.Charset im Objektinspektor.
Natürlich muss dein Windows auch ClearType- oder Truetype-Fonts installiert haben, bei denen die russischen Zeichen enthalten sind.
Die Codepage 1251 Cyrilic wird nicht von jedem Font unterstützt.

[uligerhardt]

Zitat:

Zitat von shmia (Beitrag 1059183)

Bei meinem Delphi 5 funktioniert das auf Abhieb nur durch Umstellen von Font.Charset im Objektinspektor.
Natürlich muss dein Windows auch ClearType- oder Truetype-Fonts installiert haben, bei denen die russischen Zeichen enthalten sind.
Die Codepage 1251 Cyrilic wird nicht von jedem Font unterstützt.

Im konkreten Fall ist der Font in beiden Fällen Courier New.
Kannst du bitte mal dein Projekt anhängen, am besten Quelltext + Exe, damit ich es mal auf meinem System laufen lassen kann?

[p80286]

Zitat:

Zitat von shmia (Beitrag 1059183)

Die Codepage 1251 Cyrilic wird nicht von jedem Font unterstützt.

Wahrscheinlich klemmt es hier.

Ohne den richtigen Font bist mit der Codepage ziemlich verloren.

Gruß
K-H

[uligerhardt]

Zitat:

Zitat von p80286 (Beitrag 1059189)

Zitat:

Zitat von shmia (Beitrag 1059183)

Die Codepage 1251 Cyrilic wird nicht von jedem Font unterstützt.

Wahrscheinlich klemmt es hier.

Ohne den richtigen Font bist mit der Codepage ziemlich verloren.

Wenn ich im Debugger nichts übersehen habe, ist der Font sowohl im funktionierenden als auch im nichtfunktionierenden Fall Courier New, und das Charset in beiden Fällen 204 aka RUSSIAN_CHARSET.

[shmia]

Demo-Programm im Anhang.
Courier New unterstützt die Codepages auf meinem System (Windows XP SP3).

[uligerhardt]

Zitat:

Zitat von shmia (Beitrag 1059193)

Demo-Programm im Anhang.

Danke!
Ich hab's jetzt rausgefunden - es ist das Theming. :wall:
Ein XPMan ins uses deines Testprogramms und bumm - nix mehr Kyrillisch. :roll:
Na, mal schauen, ob man da was machen kann...

Update: Ich bin nicht der Einzige mit dem Problem:

http://groups.google.de/group/borlan...59cb953c3e502/
http://groups.google.de/group/borlan...11b795ea52aee/

Eine Lösung habe ich aber noch nicht gefunden.

[Bernhard Geyer]

Wenn du kein Win9x/ME benötigst nimm die letzte freie Version der TNTWare-Kompos (oder die neuen von TMS) und schmeiß die Codepage/Charset-Krücke weg.

[uligerhardt]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1059240)

Wenn du kein Win9x/ME benötigst nimm die letzte freie Version der TNTWare-Kompos (oder die neuen von TMS) und schmeiß die Codepage/Charset-Krücke weg.

Da hätte ich mal ne Frage - hab leider kein Delphi hier, um's auszuprobieren: Der Benutzer kann dann in ein TNT-Edit das komplette Unicode-Spektrum eingeben, sagen wir auf einem russischen System auch griechische oder türkische (chinesische? arabische?) Zeichen, richtig? Was passiert dann, wenn ich die ohne irgendwelche Umcodierungen direkt als AnsiString (genauer gesagt als string[N]) speichere, also:

Delphi-Quellcode:

type
  TMyStoredRecord = record
    EinString: string[50];
  end;
var
  rec: TMyStoredRecord;
begin
  rec.EinString := TntEdit1.Text;
...

Das ist ja wohl verlustbehaftet. Kann mas das TNT-Edit irgendwie veranlassen, nur "passende" Eingaben zuzulassen? Und wenn wir schon dabei sind: Wie wäre das mit einem Unicode-VCL-TEdit?

[mkinzler]

Der Inhalt solcher Komponenten ist dann WideString.

[himitsu]

Zitat:

Zitat von uligerhardt (Beitrag 1059247)

Der Benutzer kann dann in ein TNT-Edit das komplette Unicode-Spektrum eingeben, sagen wir auf einem russischen System auch griechische oder türkische (chinesische? arabische?) Zeichen, richtig?

Ja

Zitat:

Zitat von uligerhardt (Beitrag 1059247)

Was passiert dann, wenn ich die ohne irgendwelche Umcodierungen direkt als AnsiString (genauer gesagt als string[N]) speichere,

Wenn du es nicht selber umkodierst, dann wird die CodePage des Systems zum Speichern verwendet.
Also auf einem russischen System wird nur der rusische Teil in ANSI gespeichert.
Ließt man nun diesen AnsiString in einem anderem System aus, so wird da ebenfalls die SystemCodePage verwendet und es wird falsch ausgelesen.

Also lieber WideString nutzen, oder

Delphi-Quellcode:

TMyStoredRecord = record
  EinString: array[1..50] of WideChar;
end;

[uligerhardt]

Zitat:

Zitat von himitsu (Beitrag 1059250)

Zitat:

Zitat von uligerhardt (Beitrag 1059247)

Was passiert dann, wenn ich die ohne irgendwelche Umcodierungen direkt als AnsiString (genauer gesagt als string[N]) speichere,

Wenn du es nicht selber umkodierst, dann wird die CodePage des Systems zum Speichern verwendet.
Also auf einem russischen System wird nur der rusische Teil in ANSI gespeichert.
Ließt man nun diesen AnsiString in einem anderem System aus, so wird da ebenfalls die SystemCodePage verwendet und es wird falsch ausgelesen.

Das ist in unserer Anwendung ja bisher schon so, also erstmal keine Verschlechterung.

Zitat:

Zitat von himitsu (Beitrag 1059250)

Also lieber WideString nutzen, oder

Delphi-Quellcode:

TMyStoredRecord = record
  EinString: array[1..50] of WideChar;
end;

Das geht eben nicht, ohne eine Unmenge von Code anzufassen. Das wollen wir momentan vermeiden. Für eine Prüfung, ob nicht in der Codepage vefügbare Zeichen eingegeben wurden, finde ich vermutlich eine zentrale Stelle, um den Benutzer dann zu warnen. (Wenn es keine in die Unicode-Edits eingebaute Möglichkeit gibt.)

[himitsu]

Da D2007 Recordoperatoren bietet, könnte man für das WideChar-Array einen Ersatz stellen, welcher 100%ig wie ein WideString nutzbar ist und zugleich die Vorteile des ShortString/CharArray bietet.
http://www.delphipraxis.net/129846-c...l-einfach.html
Gut, bei gespeicherten Records müßte man die Dateien/Recorddaten erstmal konvertieren.

[uligerhardt]

Zitat:

Zitat von himitsu (Beitrag 1059264)

Da D2007 Recordoperatoren bietet, könnte man für das WideChar-Array einen Ersatz stellen, welcher 100%ig wie ein WideString nutzbar ist und zugleich die Vorteile des ShortString/CharArray bietet.
http://www.delphipraxis.net/129846-c...l-einfach.html
Gut, bei gespeicherten Records müßte man die Dateien/Recorddaten erstmal konvertieren.

Hmm, in de Richtung habe ich schon mal mit der XE-Trial rumgespielt. Leider habe ich es nicht fertiggebracht, ein generisches Unicode-string[N]-Äquivalent zu bauen, da man ja die Größe nicht Compilezeit-konstant hinkriegt. Ich hätte ja gern

Delphi-Quellcode:

FixedSizeUnicodeString<N: Integer>

genommen, aber das geht schon mal gar nicht. Als Notbehelf dachte ich an

Delphi-Quellcode:

FixedSizeUnicodeString<BaseT>

, den ich z.B. als

Delphi-Quellcode:

var s50: FixedSizeUnicodeString<string[50]>

o.ä. instantiiert hätte, aber auch da ging nix. Habt ihr da schon mal eine funktionierende Lösung gesehen?

[himitsu]

Nee, leider gibt es keine Möglichkeit, um bei den Generics Nummern zu übergeben.
Und wenn man den Speicher als

Delphi-Quellcode:

String[x]

oder

Delphi-Quellcode:

array[0..x] of Char

als Parameter übergibt, dann kann man nicht innerhalb des generischen Typs darauf zugreifen, um die nötigen Konvertierungen für die Operatoren zu implementieren.

Praktisch sind die Generics dafür komplett nutzlos. :evil:

Von der Sprache/Syntax her wäre es schon möglich den Generigs etwas von Makros mitzugeben oder eben, daß man nicht nur Typen, sondern auch Werte (Nummern oder Strings) als "Parameter" an den Generic übergibt ... aber ob Emba jemals sowas Cooles in die Generics einbaut? (wäre immerhin ein Pluspunkt gegenüber den anderen Programmiersprachen, welche Generics kennen)

Der Einzige Ausweg blieb halt nur noch ein "blödes" Template, über welches man sich zumindestens passende Typen basteln könnte.



Da die Generics nur einmal geparst und sofort auf Syntax und Typverträglichkeit geprüft werden, wo der ersetzende Typ noch nichtmal bekannt ist, kann man da innerhalb der Generics leider nicht viel machen. :cry:
Ein mehrschichtiger Parser würde mir in Delphi wirklich gefallen, welcher die Typkompatibilität erst nach dem Ersetzen der generischen Typen prüft.

[uligerhardt]

Zitat:

Zitat von himitsu (Beitrag 1059277)

Nee, leider gibt es keine Möglichkeit, um bei den Generics Nummern zu übergeben.
Und wenn man den Speicher als

Delphi-Quellcode:

String[x]

oder als

Delphi-Quellcode:

array[0..x] of Char

übergibt, dann kann man nicht mehr innerhalb des Generischen Typs darauf zugreifen, um die nötigen konvertierungen für die operatoren hinzubekommen.

Ich hatte irgendwann mal sowas wie

Delphi-Quellcode:

FixedSizeUnicodeString<BaseT> = record
public
  const cBaseSize = SizeOf(BaseT);
strict private
  FBuffer: array[0..Pred(cBaseSize)] of WideChar;
end;

, was sich zumindest compilieren ließ. :mrgreen: Aber leider war cBaseSize immer 0, egal, welchen Typ man übergeben hat. Experimente mit constraints (z.B.

Delphi-Quellcode:

FixedSizeUnicodeString<BaseT: record>

) haben das - WIMRE - behoben, sich aber nie für BaseT = string[N] compilieren lassen.

Zitat:

Zitat von himitsu (Beitrag 1059277)

Von der Sprache/Syntax her wäre es schon möglich den Generigs etwas von Makros mitzugeben oder eben, daß man nicht nur Typen, sondern auch Werte (Nummern oder Strings) als "Parameter" an den Generic übergibt ... aber ob Emba jemals sowas Cooles in die Generics einbaut? (wäre immerhin ein Pluspunkt gegenüber den anderen Programmiersprachen, welche Generics kennen)

Manchmal vermisse ich echt C++.

Zitat:

Zitat von himitsu (Beitrag 1059277)

Der Einzige Ausweg blieb halt nur noch ein "blödes" Template, über welches man sich zumindestens passende Typen basteln könnte.

Da wir string[N] nur für eine Handvoll unterschiedliche N's brauchen, könnte ich mich ja mit etwas Copy&Paste arrangieren. Vielleicht kann man auch mit twm's Pseudo-Templates was tricksen.

[himitsu]

Zitat:

Ich hatte irgendwann mal sowas wie

Sowas ähnliches hatte ich auch mal ausprobiert, mit dem Ergebnis, daß sich sporadisch im Code "internal copiler error" versteckten.

Das Problem ist halt, daß BaseT zur Compilezeit und an dieser Stelle noch nicht bekannt ist.
Leider arbeitet der Compiler nur in einem Durchgang, so daß der Code nicht nochmal übersetzt wird ... SizeOf bekommt also niemals den Ersatztypen mit, welchen man bei einer späteren Verwendung des GenTyps angibt.


Leider fehlt mir auch die Zeit, um mich mal mit einem Precompiler für Delphi zu beschäftigen und zu schauen, ob sich da etwas machen ließe. :?
(hatte zwar mal einen PreCompiler für D2005 oder 2006 gefunden, aber wenn ich jetzt suche, dann finde ich nur noch Welche für die alten Compiler ala D7 und das funktioniert unter neueren Delphis nicht mehr und ist meistens auch "unschön" gelöst)

[uligerhardt]

Zitat:

Zitat von himitsu (Beitrag 1059281)

Das Problem ist halt, daß BaseT zur Compilezeit und an dieser Stelle noch nicht bekannt ist.
Leider arbeitet der Compiler nur in einem Durchgang, so daß der Code nicht nochmal übersetzt wird ... SizeOf bekommt also niemals den Ersatztypen mit, welchen man bei einer späteren Verwendung des GenTyps angibt.

Nö, prinzipiell kennt der Compiler die Größe von BaseT schon. Noch ein (seeeehr) experimenteller Stand war nämlich sowas:

Delphi-Quellcode:

FixedSizeUnicodeString<BaseT> = record
strict private
  FBufferPart1: T;
  FBufferPart2: T;
end;

Dann hatten Instantiierungen von FixedSizeUnicodeString zumindest die richtige SizeOf. Dafür hat's dann wieder woanders gehakelt, mal abgesehen davon, dass das eine Move/FillChar/Cast/Pointerarithmetik-Orgie geworden wäre.
Aus irgendeinem Grund verrät der Compiler uns aber die Größe nicht, auch wenn er sie kennt.:evil: