TEdit-Komponente mit AnsiString

[colcok]

Ich habe mich gefragt, ob es relativ schnell zu bewerkstelligen sein müsste, die TEdit-Komponente, welche UnicodeString-Textelemente verwendet,
auf AnsiString umzubauen.
Würde man eine neue Komponente anlegen, die auf TEdit basiert, wie könnte man die Properties, etc. auf AnsiString ändern?
Ich kann den Aufwand nicht wirklich abschätzen, und wäre dankbar, wenn jemand eine Idee hätte.

[Bernhard Geyer]

Wieso soll man das wollen?
Kannst du erklären wieso du AnsiString benötigst?

Ich vermute ein überschreiben von DoChange oder Keypress-Methoden, um alle neuen Zeichen auf "IsAnsChar" sollte helfen.
Die Basis-TEdit-Komponente wirst du nicht ändern können. Dazu ist UnicodeString schon zu tief in der VCL eingebaut.

[colcok]

Vielen Dank für deine Antwort.
Die TEdit-Komponente bietet die Möglichkeit, durch Änderung des Charsets
automatisch den angezeigten Text in den entsprechenden Zeichensatz umzuwandeln.
Das funktioniert allerdings mit Unicode nicht mehr, ich hätte erwartet, dass
die Abwärtskompatibilät gegeben ist.

[Bernhard Geyer]

Zitat von colcok:

Vielen Dank für deine Antwort.
Die TEdit-Komponente bietet die Möglichkeit, durch Änderung des Charsets
automatisch den angezeigten Text in den entsprechenden Zeichensatz umzuwandeln.
Das funktioniert allerdings mit Unicode nicht mehr, ich hätte erwartet, dass
die Abwärtskompatibilät gegeben ist.

Dieses Property war m.W. eher ein Mapping auf das Alte Charset/Codepage-Verhalten der Nicht-Unicde-API von Windows (Kann mich aber täuschen).
Da dieses Property immer noch vorhanden ist, wird dem geschuldet sein, das sonst viele dfm-Dateien beim Laden krachen würden.
Da das Nutzen seit D2009 doch sehr gering ist, wird keiner bei Emba auf irgendwelche Alte/Ansi-Kompatiblität mehr geachtet haben.

Also selber Entwickeln als auf seit über 20 Jahren nur noch wegen "damits nicht kracht"-Properties verlassen.

[colcok]

Verstehe, vielen Dank für die Informationen, dann werde ich mein Glück mit einer
geänderten TEdit-Komponente versuchen.

[himitsu]

CreateWindowA('EDIT', ....)
und schon hat man ein "TEdit" als ANSI auf der Form.

Aber dennoch, warum unbedingt umständlich die Komponente als ANSI?

Im OnChange kann man die Eingabe unmittelbar prüfen, um dem Nutzer zu sagen "nee, so nicht"
und beim Auslesen lösst sich das Unicode problemlos in ANSI umwandeln.
Beim Umwandeln dann ungültige Zeichen als '?' oder man wirft eine Fehlermeldung
und fertig.

Stichworte: WinAPI, NonVCL

Delphi-Quellcode:

var
  H: HWND;
  S: AnsiString;
begin
  H := CreateWindowA('EDIT', 'Text 123', 0, 100, 50, 121, 21, Self.Handle, 0, HInstance, 0);

  SetLength(S, GetWindowTextLengthA(H));
  GetWindowTextA(H, PAnsiChar(S), Length(S) + 1);
  ShowMessage(S);