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);

[colcok]

Danke für die WINAPI-Variante, gefällt mir auch.
Ja, im Prinzip lässt es sich leider nicht vermeiden, eigene Umwandlungen einzubauen,
mich hatte eben nur interessiert, warum die Komponente die Funktionalität nicht mehr
liefert (Abwärtskompatibilität), das wurde jedoch bereits geklärt.
Weiterhin hatte mich interessiert, wie viel Aufwand es wäre, eine eigene Komponente
zu implementieren, und wo man dort anzusetzen habe, auch das ist mir nun klar.
Ich habe eben mal deinen WINAPI-Code in C++ umgewandelt, der Text wird in der MessageBox
angezeigt, doch sehe ich leider kein Editfeld. Wo ist der Fehler?

Code:

__fastcall TForm1::TForm1(TComponent* Owner)
  : TForm(Owner)
{
 HWND H = CreateWindowA("EDIT", "Submit",
                 WS_CHILD,
                 10, 10, 124, 25,
                 Handle,
                 NULL,
                 HInstance,
                 NULL);


   AnsiString S;

   S.SetLength(GetWindowTextLengthA(H));
   GetWindowTextA(H, S.c_str(), S.Length() + 1);
   ShowMessage(S);
}

Und wie könnte ich hier jetzt z.B. das Charset probeweise ändern?

[tomkupitz]

WS_VISIBLE fehlt

[himitsu]

Die TEdit-Komponente ableiten und mindestens die Stelle anpassen, wo das CreateWindow ausgeführt wird.
Und dann eben das neue TAnsiEdit in der IDE registrieren und verwenden.

Außerdem kannst in TEdit/TCustomEdit dir abgucken, wie das mit den Charsets an Windows übergeben wird.


oder (ein Doppel-Beispiel, nur halt andersrum)
https://www.delphipraxis.net/141895-...phi-other.html


oder ein älteres Delphi nutzen, also Delphi 2 bis Delphi 2007


und dann gäbe es noch FreePascal/Lazarus ... das ist noh "halb" auf ANSI, nur wird da an vielen Stellen die CodePage für UTF-8 verwendet.

[colcok]

Okay, dank euch, konnte eine Editbox mit dem SetWindowPos-Aufruf sichtbar machen,
auch wenn sie etwas rudimentär ausschaut, aber das ist auch nicht wichtig.

Wäre es im Prinzip ausreichend, folgenden Code in onChange zu setzen?

Code:

void __fastcall TForm1::edtBox(TObject *Sender)
{
  TEdit *DBBoxChange = dynamic_cast<TEdit *>(Sender);
  int codepage = readCodepage();
  RawByteString rbStr(DBBoxChange->Text);
  SetCodePage(rbStr, codepage, false);
  
  DBBoxChange->Text = rbStr;
}