Sonderzeichen in TEdits (Charset?)

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

[uligerhardt]

Zitat von himitsu:

Nee, leider gibt es keine Möglichkeit, um bei den Generics Nummern zu übergeben.
Und wenn man den Speicher als String[x] oder als 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ß. Aber leider war cBaseSize immer 0, egal, welchen Typ man übergeben hat. Experimente mit constraints (z.B. FixedSizeUnicodeString<BaseT: record> ) haben das - WIMRE - behoben, sich aber nie für BaseT = string[N] compilieren lassen.

Zitat von himitsu:

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

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

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.