Bei mehr als 255 Zeichen im Eingabefeld springt der Cursor beim editieren immer an den Anfang zurück

Hallo,

was spricht dagegen, wenn es nur um eine Begrenzung der möglichen Eingabelänge geht, dies im Klassenassistenten festzulegen (falls VC++ 6 benutzt wird), statt auf EN_CHANGE zu reagieren?

MfG

Wie meinst Du das?

Ich meine: Sobald der Text im Feld verändert wird soll die Textlänge aktualisiert werden, also EN_CHANGE: strlen(CString).

Ich weiß nicht was Du meinst.

das liegt wohl daran, daß ich nicht weiß, was du meinst. Was hat das "Springen" des Carets (nicht Cursor ) mit der Ermittlung der Länge zu tun? Du mußt also da irgendetwas seltsames tun, wenn das Caret zurückspringt, mehr kann man ohne weiteren Quelltext nicht sagen. Außerdem verwendet man kaum strlen, wenn es doch die Methode GetLength von CString gibt, aber das nur als Anmerkung am Rande.

MfG

Jetzt habe ich strlen(CString) durch Cstring.GetLength() ersetzt, das Phänomen ist das gleiche.

Die Funktion die aufgerufen werden soll wenn sich die Länge des Strings im Feld ändert:

void CSchriftcodiererDlg::OnChangeEdtextout() 
{
	UpdateData(1);
	m_iCResult=m_strTextOut.GetLength();
	UpdateData(0);
}

der Hinweis auf GetLength sollte nur eine Anmerkung sein, er hat natürlich nichts mit dem Problem zu tun. Aber jetzt kann man wenigstens sehen, was das Problem ist: du benötigst doch kein UpdateData(FALSE) am Ende, es reicht so:

void CSchriftcodiererDlg::OnChangeEdtextout() 
{
    // nicht UpdateData(1), ist zwar das gleiche, besser aber UpdateData(TRUE), oder eben ohne Argument aufrufen, da TRUE default ist:
    UpdateData();
    m_iCResult=m_strTextOut.GetLength();
}

MfG

Und ob ich das brauche, die String Länge steckt doch in einer Member-Variable also wird die wohl dann auch ausgegeben. Dementsprechend muss der Inhalt der Variable mit dem Dialog abgeglichen werden.

wenn ich es jetzt richtig verstanden habe, dann ist auch m_iCResult an ein Steuerelement gebunden, und der Wert soll in diesem anderen Element erscheinen (denn das würde das UpdateData(FALSE) am Ende erklären)?

Wenn ja, dann kann man offensichtlich nicht mit UpdateData(FALSE) am Ende arbeiten, denn wenn du es ausprobiert hast, müßtest du erkannt haben, daß jetzt (ohne UpdateData(FALSE)) das Caret nicht mehr an den Anfang springt. Also muß eine andere Vorgehensweise her, d.h. statt UpdateData(FALSE) verwendest du z.B. SetDlgItemInt oder mit GetDlgItem erst das Steuerelement holen und dann SetWindowText oder, oder...

MfG

Ja, das ist mir auch aufgefallen, dass das Caret nicht springt falls keine UpdateData(0) vorhanden ist.

Nun gut, wenn Deine Idee die Lösung ist dann bitte ich Dich mir mal den Befehl für meinen Fall zu nennen mit Paramtern und so.

Würd mich nur interessieren warum dass nicht mit der UpdateData-Funktion geht, wäre doch viel schöner.

hier die Lösung mit SetDlgItemInt:

void CSchriftcodiererDlg::OnChangeEdtextout() 
{
    UpdateData();
    m_iCResult=m_strTextOut.GetLength();
    // IDC_EDIT1 ist das Steuerelement, in dem der Wert m_iCResult angezeigt werden soll
    SetDlgItemInt(IDC_EDIT1, m_iCResult);
}

eigentlich ist es nicht schöner, hierfür UpdateData einsetzen zu wollen, weil UpdateData nicht gezielt ein Steuerelement ansprechen kann, die aufgerufene Routine ist dafür gedacht, mehrere Elemente zu aktualisieren. Warum also UpdateData, wenn man auch gezielt das gewünschte Element aktualisieren kann? Es ist immer kritisch, wenn man in einer Ereignisbehandlungs-Routine wie OnChange die gleiche Member-Variable, die eigentlich hier verändert wird, gleich wieder aktualisiert (du willst zwar ein anderes Element aktualisieren, aber mit UpdateData erwischt du eben auch die Member-Variable, die sich gerade in der Ereignisbehandlungs-Routine ändert). Hier kommt die MFC-Implementierung durcheinander, und das äußert sich hier im Zurücksetzen des Carets. Warum das gerade bei 255 Zeichen passiert, ist mir eigentlich egal, man muß nur wissen, daß es zu "komischen Effekten" kommen kann, wenn die obige Situation vorliegt. Aber man weiß dann wenigstens, was man nicht tun sollte in einer Ereignisbehandlungs-Routine, zumindest nicht in dieser für ein CEdit. Wenn es dich weiter interessieren sollte, kannst du ja in den Quell-Code der MFC hinein debuggen, um zu sehen, was hier passiert, vielleicht kann man da etwas erkennen. Ich habe dazu aber jetzt keine Lust und weiß nur, daß man in solchen Fällen aufpassen muß, und auf UpdateData verzichten muß.

MfG

JUHUUUUUUUUUUUUUU
es funktioniert...

Ich Danke Dir Probe-Nutzer... wenn Du Lust und Zeit hast kannst Du Dir ja noch meine anderen Threads anschauen, Du hast mir sehr geholfen.

Danke nochmal