Hi,
In an MFC application, I have several text edit controls that are
monitored (through the EN_CHANGE event / ON_EN_CHANGE handler)
to immediately update some output values.
However, as a result of a change of one field, I may have to
'automatically' change the content of another field.
To avoid any callbacks (and potentially infinite recursion),
I would like to be able to set the contents of a text edit
field without triggering the ON_EN_CHANGE callback of the
containing dialog.

Do you know of a proper way to do so ?
An approach I could think of is to temporarily change the
parent of the text field (e.g. to NULL), but it's kind of
ugly. Any other ideas ?

Thanks,
Ivan

--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

"Ivan Vecerina" <_INVALID_use_webform_@_ivan.vecerina.com_> wrote in message
news:1b717$450842d0$3e028af2$7133@news.hispeed.ch. ..
Yeah. Set a flag.
Are you sure setting the text of an edit sends EN_CHANGE? I seem to recall
it doesn't but can't find it in the ever-so-handy MSDN.

[Jongware]

"[jongware]" <jongware@post.in.group.plz> wrote in message
news:9b299$45085826$50388373$11807@news.chello.nl. ..
If the control is multi-line (ES_MULTILINE), EN_CHANGE is not sent after
WM_SETTEXT. See
http://windowssdk.msdn.microsoft.com.../ms672110.aspx

Beats me why Microsoft should draw a distinction based on multi-line

Ivan Vecerina wrote:

I had a similar issue few days ago. It can be resolved by using "inteligent" update routine. Search for "Synchronize two edit boxes" thread in this newsgruoup.

--
Grzegorz Wróbel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D

"Grzegorz Wróbel" </dev/null@localhost.localdomain> wrote in message
news:eeap09$k1v$1@atlantis.news.tpi.pl...
: Ivan Vecerina wrote:
:
: > Hi,
: > In an MFC application, I have several text edit controls that are
: > monitored (through the EN_CHANGE event / ON_EN_CHANGE handler)
: > to immediately update some output values.
.....
: > An approach I could think of is to temporarily change the
: > parent of the text field (e.g. to NULL), but it's kind of
: > ugly. Any other ideas ?
: >
:
: I had a similar issue few days ago. It can be resolved by using
: "inteligent" update routine. Search for "Synchronize two edit boxes"
: thread in this newsgruoup.

I actually already check for the previous value of the field
(i.e. SetText called only if GetText != myNewText).
Yet in my application this is not enough: I have several fields
that are kept in sync. And sometimes an external event sets the
stored data(/Model), and the controller then needs to update
the display(/View). The callback from a first text field being
set may cause other fields in the model to be overwritten with
"old" view contents.

Of course there are ways around this (extra flags, etc), yet
it would seem so natural/fundamental to have a "silentSetText"
routine that does not trigger any callback (if it's not the default).
Actually, I have been pointed towards another (undocumented)
solution available in MFC: setting (then restoring)
AfxGetThreadState()->m_hLockoutNotifyWindow to the handle
of the dialog -- which temporarily silences the callback.
I might go for this solution, although I don't like it.


All other controls (sliders, combo/lists, checkboxes) have a way
to independently monitor user-made changes from programmatical
value changes. So this exception is ugly and unfortunate IMO.


With my thanks to all of you for your replies,
Ivan


--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

Ivan Vecerina wrote:

I have once (years ago) implemented superclassed edit control, which has among few other things such feature that you could conjugate one editbox with another so when you type text in one it would automatically appear in the second that is conjugated with it without sending any messages. You can check it in my 1Fh binary/hex editor: http://www.4neurons.com/1Fh/ - the conjucted editboxes are in the "Find" and "Replace" dialogboxes.

You could extend this technique to connect a larger group of editboxes that way, but if the only thing you want is synchronizing a group of editboxes this approach might be an overkill. But at least it would be an ellegant approach. Of course the EN_CHANGE would still be generated but since you don't use it for synchronizing, you don't care. The final values in the synchronized group would always correspond to the last update to whichever of the editboxes in the group.

--
Grzegorz Wróbel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D