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

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!

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

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!

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

Und warum?

So Leute, macht mich fertig!

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.

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