Re: DDX problem: Is DDX even worth the trouble?
On 23 Aug 2006 19:38:04 -0700, "scs0" <scs0@vol.com> wrote:
Here's the problem. I have a dialog with 2 edit controls. Each
control has a DDX string assignment on it, and each edit control has a
handler for EN_CHANGE. I have an initialization function that sets
these strings and then I call DoDataExchange(false) to send the
information from the strings to the UI. The EN_CHANGE messages
handlers are designed to call DoDataExchange(false) to pull values from
the UI and set them into my strings.
So basically what happens is I initialize the two values, call
DoDataExchange(false) to update the UI, then UI then fires off
EN_CHANGE messages which are handled and call DoDataExchange(true) to
read the values from the UI. This means that one of my strings gets
reset to empty!
First of all, why is EN_CHANGE called from DoDataExchange(false)? I
always thought that the benefit of using DDX was that it could change
the contents of the UI without causing the change notification messages
to be sent. This is the first time I've ever noticed this happening.
At this point I don't understand the point of using DDX at all.
You should use UpdateData instead of DoDataExchange, and then only when you
want to transfer and validate ALL controls participating in DDX/DDV. (It's
not possible to overemphasize the word "ALL" in the preceding sentence.)
I'm not aware that the mechanism was ever intended to suppress EN_CHANGE or
other notifications. A general way to ignore unwanted notifications (or
more to the point, unwanted reentrancy) is to set a bool member of your
dialog class to true before the call, test it in handlers, and reset it
after the call. I wrote a couple of class templates to accomplish this in
an exception-safe way:
template<class T>
class RuntimeValueManager
{
public:
RuntimeValueManager(
T& var,
const T& ctorValue,
const T& dtorValue)
: m_var(var),
m_dtorValue(dtorValue),
m_dtorReset(true)
{
m_var = ctorValue;
}
~RuntimeValueManager()
{
if (m_dtorReset)
m_var = m_dtorValue;
}
void Cancel()
{
m_dtorReset = false;
}
private:
// Copyguard.
RuntimeValueManager(const RuntimeValueManager&);
void operator=(const RuntimeValueManager&);
private:
T& m_var;
T m_dtorValue;
bool m_dtorReset;
};
template<class T, T ctorValue, T dtorValue>
class ValueManager
{
public:
explicit ValueManager(T& var)
: m_var(var),
m_dtorReset(true)
{
m_var = ctorValue;
}
~ValueManager()
{
if (m_dtorReset)
m_var = dtorValue;
}
void Cancel()
{
m_dtorReset = false;
}
private:
// Copyguard.
ValueManager(const ValueManager&);
void operator=(const ValueManager&);
private:
T& m_var;
bool m_dtorReset;
};
typedef ValueManager<bool, true, false> BoolTrueValueManager;
typedef ValueManager<bool, false, true> BoolFalseValueManager;
typedef ValueManager<volatile bool, true, false>
VolatileBoolTrueValueManager;
typedef ValueManager<volatile bool, false, true>
VolatileBoolFalseValueManager;
The difference between RuntimeValueManager and ValueManager is that the
former allows you to choose the ctor and dtor values at runtime, while the
latter fixes them at compile-time. If I understand your problem correctly,
this would solve it, the idea being to eliminate reentrant DoDataExchange:
// In dialog box ctor...
m_inDoDataExchange = false;
// At top of DoDataExchange override...
if (m_inDoDataExchange)
return;
BoolTrueValueManager btvm(m_inDoDataExchange);
Again, using UpdateData is inappropriate unless you want to transfer and
validate all controls participating in DDX/DDV. If you don't want to do
this, use functions like SetWindowText. To ignore unwanted EN_CHANGE in
that scenario, write your EN_CHANGE handler like this:
if (m_in_EN_CHANGE)
return;
BoolTrueValueManager btvm(m_in_EN_CHANGE);
// Now do things that can cause EN_CHANGE
The usage pattern should be clear by now.
--
Doug Harrison
Visual C++ MVP