Sonderzeichen in TEdits (Charset?)

[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 von 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.

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 von uligerhardt:

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 von uligerhardt:

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 von himitsu:

Zitat von uligerhardt:

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 von himitsu:

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 von 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.

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 FixedSizeUnicodeString<N: Integer> genommen, aber das geht schon mal gar nicht. Als Notbehelf dachte ich an FixedSizeUnicodeString<BaseT> , den ich z.B. als 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 String[x] oder 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.

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.
Ein mehrschichtiger Parser würde mir in Delphi wirklich gefallen, welcher die Typkompatibilität erst nach dem Ersetzen der generischen Typen prüft.