Edit Control: Automatisch mitscrollen bei SetWindowText(...)

crazychicken

Hallo Leute,
ich habe folgendendes Problem: In meinem Programm verwende ich eine
Editbox mit den Eigenschaften WS_CHILD | ES_AUTOHSCROLL | WS_BORDER | WS_VISIBLE
- es handelt sich also um ein einfaches Textfeld, in welchem ich beliebig viele
Zeichen darstellen kann.
Benutzereingaben können direkt in das Textfeld aufgenommen werden; aber auch mein Programm ändert mittels SetWindowText den Inhalt der Box.
Das Problem ist: Ich weiß nicht, wie ich die Box mitscrollen lassen kann, wenn das Programm mit SetWindowText(...) einen String in der Box ausgibt, der die Länge der Box wesentlich überschreitet.
Dargestellt werden in dem Falle nur die ersten Zeichen des Strings - es sollen aber die letzten angezeigt werden.
Scrollbalken sollen wenn möglich nicht verwendet werden.

Wie ist ein "mitscrollen" in der Textbox möglich?

Blaze

Der Trick ist ganz einfach: Der Cursor muss ans Ende gesetzt werden.
Erst schicks du eine EM_SETSEL Message an die Editbox, als lParam und wParam benutzt du bei beiden die Anzahl der Buchstaben (GetWindowTextLength), damit nichts markiert wird aber der Cursor ganz am Ende ist.

HWND hEditText; // <-- Deine EditBox
...
int iLength= GetWindowLength(hEditText);
SendMessage(hEditText, EM_SETSEL, static_cast<WPARAM>(iLength), static_cast<WPARAM>(iLength));

Das machst du jedesmal, wenn dein Programm die Message EN_CHANGE erhalten hat,
bzw. (ich weis jetzt nicht ob das unbedingt nötig ist) sendest diese Nachricht, nachdem dein Programme etwas an dem EditText geändert hat.

So sollte es funktionieren!

berniebutt

Das geht vielleicht mit einem SendMessage an die Editbox, das aus dem Programm das Scrollen nach unten macht. Dafür habe ich aber keine eigene Erfahrung. Irgendwie geht aber alles mit WinApi.

CStern

crazychicken schrieb:

Hallo Leute,
ich habe folgendendes Problem: In meinem Programm verwende ich eine
Editbox mit den Eigenschaften WS_CHILD | ES_AUTOHSCROLL | WS_BORDER | WS_VISIBLE
- es handelt sich also um ein einfaches Textfeld, in welchem ich beliebig viele
Zeichen darstellen kann.
Benutzereingaben können direkt in das Textfeld aufgenommen werden; aber auch mein Programm ändert mittels SetWindowText den Inhalt der Box.
Das Problem ist: Ich weiß nicht, wie ich die Box mitscrollen lassen kann, wenn das Programm mit SetWindowText(...) einen String in der Box ausgibt, der die Länge der Box wesentlich überschreitet.
Dargestellt werden in dem Falle nur die ersten Zeichen des Strings - es sollen aber die letzten angezeigt werden.
Scrollbalken sollen wenn möglich nicht verwendet werden.

Wie ist ein "mitscrollen" in der Textbox möglich?

Hallo,
das geht ganz einfach mit SendMessage.

SendMessage(TextBox.hwnd, EM_SETSEL, 0, (LPARAM)-1);

und nix da mit static oder gar reinterpret casten

Martin Richter

CStern schrieb:

das geht ganz einfach mit SendMessage.

SendMessage(TextBox.hwnd, EM_SETSEL, 0, (LPARAM)-1);

und nix da mit static oder gar reinterpret casten

static_cast ist Deinem Hammer-C Cast in jedem Falle vorzuziehen!

Martin Richter schrieb:

static_cast ist Deinem Hammer-C Cast in jedem Falle vorzuziehen!

Und warum?

_matze

In dem Fall machen static_cast und C-Cast sowieso dasselbe. Und solange man weiß, was man tut, geht mit C-Casts ja auch nix schief. Ich persönlich finde es so einfach schöner zu lesen, die C++-Casts bauschen den Code doch sehr stark auf. Auch den typischen reinterpret_cast (z.B. 4 Byte Pointer nach long) mache ich lieber im C-Style, mal davo abgesehen, dass das in unserem Code sowieso sehr verbreitet und damit quasi Firmen-Standard ist .

So Leute, macht mich fertig!

Martin Richter

_matze schrieb:

In dem Fall machen static_cast und C-Cast sowieso dasselbe. Und solange man weiß, was man tut, geht mit C-Casts ja auch nix schief.

Klar machen Sie hier das selbe. Da sage ich auch nichts dagegen. Deshalb ist funktionierender Code dennoch nicht imer gut geschrieben.

Und erzähl mir nicht, das ein static_cast nicht im Zweifel sicherer wäre!

_matze schrieb:

Ich persönlich finde es so einfach schöner zu lesen, die C++-Casts bauschen den Code doch sehr stark auf.

Das ist reine Gewöhnungssache.
Als ich den errszen template Code mit der stl und iteratoren gesehen habe, war mein erster Gedanke: Das sieht ja grauenhaft aus, wer will das denn schreiben?
Heute hat man sich dran gewöhnt.

_matze schrieb:

Auch den typischen reinterpret_cast (z.B. 4 Byte Pointer nach long) mache ich lieber im C-Style, mal davo abgesehen, dass das in unserem Code sowieso sehr verbreitet und damit quasi Firmen-Standard ist .

Ach Und weil es alle machen ist es gut? Nette Rechtfertigung.
Echt argumentativ tiefgreifend

Wie gut, dass ich in meiner Firma mitverantwortlich bin für das was "Standard" ist.

_matze schrieb:

So Leute, macht mich fertig!

Brauch ich doch gar nicht! Ich habe nämlich meine eigene Meinung und solange Du nicht in meiner Firma arbeitest haben wir kein Problem.
Solltest Du jedoch mal Code für meine Firma schreiben oder unter mir arbeiten müssen, dann weiß ich wie Dein Code aussehen wird... Du kannst raten....

Du kannst ja mal eine Diskussion über C casts und C++ cast im C++ Forum anstossen. Mal sehen was die Puristen dazu sagen. Vielleicht wird Dir da ja Dein Wunsch nach "fertig machen" erfüllt.

crazychicken

Also ich hab mich jetzt für

SendMessage(hEditAusgabe, EM_SETSEL, 0, (LPARAM)-1);

entschieden, auch wenn ich mir damit nen paar Feinde mach
Hab bis jetzt meine Typumwandlungen immer so vorgenommen - aber einfach aus dem Grund, dass ich mich bis jetzt noch nicht näher mit Cast-Operatoren in C++ auseinandergesetzt habe.
Vorläufig jedenfalls werde ich noch C-Casts verwenden, nehme mir aber vor, den Code noch einmal zu überarbeiten. Ich benutze ziemlich häufig Typumwandlungen in meinem Programm; da werde mich mal weiter mit den Cast-Operatoren in C++ auseinandersetzen und dann entsprechende Anpassungen vornehmen.
C++ stellt nunmal diese Operatoren zur Verfügung - warum sollte man sie nicht nutzen. Vor allem bei größeren Projekten sehe ich da Vorteile, was die Sicherheit betrifft und ich denke auch, dass so mancher Fehler in der Semantik eher gefunden werden kann.
Korrigiert mich, wenn ich da falsch liege.

Vielen Dank