Is DDX & DDE popular?

[Brad]

Hello.
Do people still use DDX & DDV or is it too 'restrictive' ?

I can imagine situations when dialogs have 'simple' controls in them, but I
have an edit control where the 1st char is an alpha, and the remaining 4 are
numeric. How does one go about validating that? Also, what about more
complex scenarios?

...Or do people do the getting/receiving & validating of the data in the
InitInstance() and OnOK() ?

Cheers,
brad.

[David Lowndes]

>...Or do people do the getting/receiving & validating of the data in the
>InitInstance() and OnOK() ?

For non-standard data I often do the initialisation in OnInitDialog,
and the customised getting/checking in the DoDataExchange function.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Randy Sanders]

Have you gotten any custom DDX and DDV functions to work with the VC .NET
wizards?

"David Lowndes" <dav...@mvps.org> wrote in message
news:briaiv08rrm9t5037...@4ax.com...

[David Lowndes]

>Have you gotten any custom DDX and DDV functions to work with the VC .NET
>wizards?

In all the time I've used MFC I've never needed to write a reusable
custom DDX/DDV - so my answer is no - but only because I've never
tried!

[Brad]

No i havn't - I havn't tried.

"Randy Sanders" <ran7...@7striker7-sy7stem7s.com> wrote in message
news:eYzwo$SVDHA...@TK2MSFTNGP09.phx.gbl...

[Brad]

OK. So that means even with the more 'complex' controls (custom or
otherwise) on your dialog, you still use DDX and DDV (not my typo of DDE)
for the getting, setting and validation of the data. ?

brad.

"David Lowndes" <dav...@mvps.org> wrote in message
news:briaiv08rrm9t5037...@4ax.com...

[Joseph M. Newcomer]

I find the DDV mechanism ill-designed and inappropriate. In addition, I prefer to do
on-the-fly validation, not validation-on-OK.

Take a look at my Validating Edit Control on my MVP Tips site. While the example shown is
to validate floating-point numbers, the actual creation was to validate part numbers of
the form
[A-Z][0-9]+(-[A-Z](-[A-Z0-9]?)?)
so it would only accept
A104
B20-A
C30895-AA
C30895-A9
and so on. (Actually, it was similar to your problem: there could only be 3 or 5 digits).
So by rewriting the innards of it, you can create any kind of validation you want.
Actually, if I wanted to be fully general, I'd have done a virtual method for validation
which always returned TRUE, which you could override in various subclasses for different
kinds of validation. I leave that as an Exercise For The Reader.

OnOK is far too late to do validation. And the error messages that pop up are at the wrong
time. I don't even enable the OK button unless I have all fields validated in advance. I
will do things like pop up a tooltip if you move over the disabled OK button that explains
why the button is not enabled (if multiple causes, I have to sort them by priority order),
or I use a CStatic to indicate the reason for an error.

See my essay on dialog control management as well.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[David Lowndes]

>OK. So that means even with the more 'complex' controls (custom or
>otherwise) on your dialog, you still use DDX and DDV (not my typo of DDE)
>for the getting, setting and validation of the data. ?

Generally - yes.

I should clarify that if an edit field is limited in the characters
that it should accept, that I also prevent incorrect entry at that
stage too.

[Brad]

I thought as much. I enjoyed the aritcles on your site.And will d/l the
control.

Thank-you.
As a newbie to MFC, I agree to 'good programming practices' and hope to
learn from you more. Thanks.
Brad.

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:csvbivoqpi4qu0996...@4ax.com...

[Tom Serface]

Hi Brad,

I agree with Joe about the DDV being a little simplistic, but it does work
for most things. I've found DDX to be a very useful mechanism and I often
extend it with my own types. It's easy enough to start using it since the
managment of it is built into the IDE. If I were you, I'd try to stay
within the framework as much as possible at first and venture out when you
understand how things are working.

Tom

"Brad" <som...@nospam.com> wrote in message
news:10594970...@grimiore.conceptual.net.au...

[Doug Harrison [MVP]]

Brad wrote:

Below are some excerpts from past messages I've written on the subject of
UpdateData/DDX/DDV.

You should use UpdateData only when you want to transfer and validate all
controls participating in DDX/DDV. When you need to do single controls, call
member functions such as GetWindowText and SetWindowText on the control
variables you created for them in ClassWizard.

In a nutshell, here's what I think you need to know about UpdateData:

1. Call UpdateData(TRUE) only when you want to transfer and validate _all_
dialog data participating in DDX/DDV. The direction of the transfer is
from the controls to the value member variables (the "m_vars"), and the
contents of the m_vars should be considered reliable following
UpdateData(TRUE) if and only if UpdateData(TRUE) returned true.

2. Call UpdateData(FALSE) only when you want to transfer data from _all_ the
m_vars to the controls.

3. UpdateData calls your DoDataExchange override to perform the transfer and
validation. Adding code to DoDataExchange is a valuable technique for
performing higher-level validation than is offered by DDV; you can test the
CDataExchange::m_bSaveAndValidate member to determine the direction of the
transfer. DoDataExchange also contains the DDX_Control calls which bind
control variables to dialog controls; this subclasses the dialog controls
and is absolutely essential to the correct operation of these control
variables.

Knowing what UpdateData does allows an MFC programmer to use it properly,
and it's actually a very useful function when used properly. The real
weakness of MFC's dialog data mechanism as embodied in UpdateData is that
it's all controls or nothing, and you can't easily leverage it to work with
individual controls. A better design would let you plug transfer and
validator objects into control variables which you could use easily and
individually. But when you need the all or nothing UpdateData behavior,
you've got it, and the "better design" would include something equivalent to
it, and it would use it in the way MFC currently uses UpdateData.

Briefly, here's my approach to dialog data. It's valid until
CDialog::OnInitDialog() is called, which does the initial UpdateData(FALSE),
to transfer the contents of the m_vars to the controls. Afterwards, it's
invalid, unless UpdateData(TRUE) has been called and returned TRUE, or
DoModal() has returned IDOK (or whatever code signifies success), which
implies UpdateData succeeded. Otherwise, you shouldn't assume a given m_var
is valid, unless you've just set it yourself.

--
Doug Harrison
Microsoft MVP - Visual C++

[Randy Sanders]

I achieved the same thing by calling UpdateData(true) in the ON_EN_CHANGE
message function for the edit control.

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:csvbivoqpi4qu0996...@4ax.com...

[Doug Harrison [MVP]]

Randy Sanders wrote:

>I achieved the same thing by calling UpdateData(true) in the ON_EN_CHANGE
>message function for the edit control.

That's exactly what you don't want to do, because it:

1. Transfers and validates all controls, so if another control is invalid,
it will pop up a message box for a different control.

2. If the current control is invalid, it will pop up a message box as the
user is typing, which would be annoying beyond belief. Under the DDX/DDV
model, the right time to do that is when he presses OK or signals in some
other way that the dialog data is good, and he wants the dialog to do its
thing, whatever that may be.

See my other message for more on how to use UpdateData correctly. An
EN_CHANGE handler should query the edit control directly, but the only point
in that is to affect the UI in some way, e.g. disabling other controls or
showing/hiding validity indicators, etc.

[Randy Sanders]

For most dialogs, I only call UpdateData during OnOK, but in some I have to
call it when EN_CHANGE is issued. To get around problem 1, all edit controls
check the EN_CHANGE and UpdateData, then there cannot be more than one with
an invalid value. To get around problem 2, I do NOT use the standard DDX and
DDV routines and use my own that have a little more intelligence to them,
like knowing that "." is valid for a decimal number if it is the only thing
entered, same with a "-".

Doing all validation when the user presses OK can cause more confusion and
frustration with our customers. Think of a dialog with 10 edit controls all
having bad values in them. The user will press OK, get a message, fix it,
press OK, get another message, fix it, press OK.... Some validation has to
occur after each edit box has data entered into it.

The other validation that we do on OK is when one value is dependant on
another value or a formula, i.e. edit control 2 must be greater than edit
control 1.

As you stated, one of the reasons for doing it during the EN_CHANGE, is when
the value is used for other display purposes. I have a dialog that has a
graph, and the edit controls affects some drawing that goes on in the graph.
I have not looked into querying the edit control directly, but will look
into it.

"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
news:r7qdivg8kq9v8kmif...@4ax.com...

[Doug Harrison [MVP]]

Randy Sanders wrote:

>For most dialogs, I only call UpdateData during OnOK, but in some I have to
>call it when EN_CHANGE is issued. To get around problem 1, all edit controls
>check the EN_CHANGE and UpdateData, then there cannot be more than one with
>an invalid value. To get around problem 2, I do NOT use the standard DDX and
>DDV routines and use my own that have a little more intelligence to them,
>like knowing that "." is valid for a decimal number if it is the only thing
>entered, same with a "-".
>
>Doing all validation when the user presses OK can cause more confusion and
>frustration with our customers. Think of a dialog with 10 edit controls all
>having bad values in them. The user will press OK, get a message, fix it,
>press OK, get another message, fix it, press OK.... Some validation has to
>occur after each edit box has data entered into it.

IME, that's such a rare occurrence that it isn't worth optimizing, and when
it does happen, it has definite pedagogic value. What about the
alternatives? How do you report the errors? Do you let the user navigate off
a bad field? I hate apps which lock me into a field until I clear it or get
it right, or which pop up a message box to tell me about it before I press
OK. Often, I will want to move to another field, copy some text, and return
and paste it. Or do you disable the OK button until everything's, well, OK?
If so, how do you tell the user the hoops he needs to jump through in order
to enable it? I guess with 10 fields, you might put a * next to each invalid
one, similar to what many web forms do, but that clutters the display and
can be distracting, when they come and go as you type, and there are a lot
of them. I would only ever consider disabling OK if it was painfully obvious
why it's disabled, so none of the secondary indicators are necessary. One of
the worst ideas that's suggested is to display a tooltip when you mouse over
OK. I shouldn't have to mouse over OK. If I can't tell what the problem is,
I should be able to press Enter and get a description, without using the
mouse.

> The other validation that we do on OK is when one value is dependant on
>another value or a formula, i.e. edit control 2 must be greater than edit
>control 1.

That's a candidate for what I mentioned in my other message, i.e. "Adding

code to DoDataExchange is a valuable technique for performing higher-level
validation than is offered by DDV; you can test the
CDataExchange::m_bSaveAndValidate member to determine the direction of the

transfer." I talked more about this and OnOK here:

http://groups.google.com/groups?selm=jtmuev8a9f4cafp9957c6uehaqrrspfc2k%404ax.com