-
January 11th, 2004, 11:14 AM
#1
check values on a dialog
Hello,
I have a MFC dialog, which has a few controls on it
When I press the OK button I would like to check that my edit box isn't empty, if it is I would like to popup a message and to leave the dialog open until the user will enter a value (or press the cancel button) where Should I i implement that (on what function) I have a CString member variable for that CEdit control, but it will have the CEdit content only after CDialog::OnOk (DoDataExchange) will be called
any ideas?
thanks
-
January 11th, 2004, 11:26 AM
#2
You usually implement that in your dialog's DoDataExchange(). Look for DoDataExchange, DDX and DDV on MSDN. Prosise also explains it very well.
-
January 11th, 2004, 11:27 AM
#3
There are several solutions. One is to override OnOk(). Another solution is to notify the user in real-time as the edit control becomes empty.
Kuphryn
-
January 11th, 2004, 11:31 AM
#4
thanks
1. on my DoDataExchange I have this:
DDX_Text(pDX, IDC_EDIT, m_sEditBoxValue);
//------------------------
is there a special function to call or just the CString function isEmpty?
2. I have just moved recently from VC6 to VC.NET and I can't seem to fine the class wizard, how do I override the OnOk function?
thanks again
avi
-
January 11th, 2004, 11:42 AM
#5
Originally posted by avi123
1. on my DoDataExchange I have this:
DDX_Text(pDX, IDC_EDIT, m_sEditBoxValue);
is there a special function to call or just the CString function isEmpty?
The DDX_Text macro transfers contents between a contol and a CString variable in both directions. You will have to check pDX->m_bSaveAndValidate and do the test only when it is TRUE. It's up to you whether you do it before you call the macro (and act upon the control) or after you call the macro (and test the string variable, e.g. with IsEmpty()). But as already said, the entire DDX/DDV mechanism is well documented, just read about it to understand the concepts.
Originally posted by avi123
2. I have just moved recently from VC6 to VC.NET and I can't seem to fine the class wizard, how do I override the OnOk function?
It is not a good idea to override OnOK. There might be other situations when you need to perform data valuation (for example, if you make you dialog modeless and add an Apply button, or if your dialog becomes a property page later). In those cases, just to mention a few, you will have to add additional overrides where you perform the same task. DoDataExchange(), in contrast, is guaranteed to be called for any of those situations, so it's the place to do any validation. After all, that's what it is for by design.
-
January 11th, 2004, 01:06 PM
#6
Originally posted by avi123
2. I have just moved recently from VC6 to VC.NET and I can't seem to fine the class wizard...
.NET does not have a wizard.
Use Property panel to insert command message handlers, windows message handlers and virtual overrides.
There are only 10 types of people in the world:
Those who understand binary and those who do not.
-
January 11th, 2004, 02:04 PM
#7
The answer to your question is to use UpdateData(TRUE) in your OnOk to get the value of the edit control. Then if the data is not correct issue an error message, then return from OnOk without calling CDialog::OnOK().
It is that simple. If you look at the MFC source code for CDialog::OnOK(), you will see that it does two things; it calls UpdateData(TRUE) and then it calls EndDialog(IDOK).
Last edited by Sam Hobbs; January 11th, 2004 at 02:14 PM.
-
January 11th, 2004, 02:11 PM
#8
Originally posted by gstercken
It is not a good idea to override OnOK.
It definitely is a good idea to override OnOK. There are plenty of places in the documentation that say so and plenty of examples of doing so.
-
January 11th, 2004, 02:30 PM
#9
Originally posted by Sam Hobbs
It definitely is a good idea to override OnOK. There are plenty of places in the documentation that say so and plenty of examples of doing so.
But not to do DDX validation, and that's what the question was about. Validation is done in DoDataExchange - straight and simple. In my previous post, I also gave some reasons why this is so.
Originally posted by Sam Hobbs
The answer to your question is to use UpdateData(TRUE) in your OnOk to get the value of the edit control. Then if the data is not correct issue an error message, then return from OnOk without calling CDialog::OnOK().
Yes, that's a complicated (and unsafe) way of doing it. It will also lead to calling DoDataExchange() twice instead of once... I don't see why one would choose such a complicated solution if the easy, straigtforward solution is so simple.
-
January 11th, 2004, 02:42 PM
#10
Originally posted by gstercken
But not to do DDX validation, and that's what the question was about.
I don't see where that is asked.
Originally posted by gstercken
Yes, that's a complicated (and unsafe) way of doing it. It will also lead to calling DoDataExchange() twice instead of once... I don't see why one would choose such a complicated solution if the easy, straigtforward solution is so simple.
It is not complicated. How is it unsafe? Also, if EndDialog is used to end the dialog without calling CDialog::OnOk, then DoDataExchange() will not be called twice.
-
January 11th, 2004, 03:00 PM
#11
Originally posted by Sam Hobbs
I don't see where that is asked.
Here:
Originally posted by avi123
When I press the OK button I would like to check that my edit box isn't empty, if it is I would like to popup a message and to leave the dialog open until the user will enter a value (or press the cancel button)
That's exactly what we call 'Dialog Data Validation', or DDV, for short. When doing the validation in DoDataExchange(), calling pDX->Fail() will do exactly what the OP requested (displaying a message box, leaving the dialog open etc.). In addition, it does other useful things, like restoring the focus and the selection to the control where the input has to be corrected. When overriding OnOK, those things had to be implemented manually, too.
Originally posted by Sam Hobbs
It is not complicated.
Not overly complicated, of course, but it's not the designed way of doing validation, and it requires more code (an estimated 3x more). That should be enough to rule it out.
Originally posted by Sam Hobbs
How is it unsafe?
As already mentioned, it is unsafe towards further extensions. When changing the dialog to modeless or to a property sheet, the validation code implemented in OnOK would have to be modified, copied or moved. Failing to remember that would lead to subtle errors (like the validation taking place when clicking OK, but not when clicking Apply and then Cancel, or when switching to a different property page.) So I don't understand why you still try to defend the less obvious way of doing things, if there is a well defined place where to do data validation which takes into account all those situations.
Originally posted by Sam Hobbs
Also, if EndDialog is used to end the dialog without calling CDialog::OnOk, then DoDataExchange() will not be called twice.
Yes, but I was obviously talking about the other case: When CDialog::OnOk is called.
-
January 11th, 2004, 10:05 PM
#12
Originally posted by Sam Hobbs
The answer to your question is to use UpdateData(TRUE) in your OnOk to get the value of the edit control. Then if the data is not correct issue an error message, then return from OnOk without calling CDialog::OnOK().
It is that simple. If you look at the MFC source code for CDialog::OnOK(), you will see that it does two things; it calls UpdateData(TRUE) and then it calls EndDialog(IDOK).
So, why bother to override OnOK to do exactly what CDialog does?
There are only 10 types of people in the world:
Those who understand binary and those who do not.
-
January 11th, 2004, 11:37 PM
#13
Originally posted by JohnCz
So, why bother to override OnOK to do exactly what CDialog does?
What he means is something like this:
void CHisDlg::OnOK()
{
UpdateData(TRUE);
if(m_sEditBoxValue.IsEmpty())
{
MessageBox("Edit box empty");
return;
}
else
{
EndDialog(IDOK);
}
}
CDialog::OnOK() does not check the edit box emptiness like what the above did.
However, though this method is correct, I would prefer doing validation of dialog's control within DoDataExchange(). Too bad DDV does not have a macro for checking whether a string is empty, so we still have to insert code explicitly to validate that. But still, it is neater to put the validation code in DoDatatExchange() than OnOK().
-
January 12th, 2004, 07:55 AM
#14
No hi did not.
But I wish all would pay better attention to posts, were the answer is already there.
Originally posted by gstercken
The DDX_Text macro transfers contents between a contol and a CString variable in both directions. You will have to check pDX->m_bSaveAndValidate and do the test only when it is TRUE. It's up to you whether you do it before you call the macro (and act upon the control) or after you call the macro (and test the string variable, e.g. with IsEmpty()). But as already said, the entire DDX/DDV mechanism is well documented, just read about it to understand the concepts.
.
.
.
Did you read this?
The matter is that you are doing unnecessary coding duplicating what CDialog class already does and you could do it with less amount of code in DoDataExchange, that can be called from many places as gstercken already mentioned.
There are only 10 types of people in the world:
Those who understand binary and those who do not.
-
January 13th, 2004, 12:10 AM
#15
Originally posted by gstercken
That's exactly what we call 'Dialog Data Validation', or DDV, for short.
No, "Dialog Data Validation" is one way of validating the data, but it is not the only way. You are entitled to always use DDV for data validation and it is good for you to suggest it as a possibility, but you are insisting that your way is the only correct way.
Originally posted by gstercken
When doing the validation in DoDataExchange(), calling pDX->Fail() will do exactly what the OP requested (displaying a message box, leaving the dialog open etc.).
Is Wombat correct? Does DoDataExchange not validate for an empty string? If so, then DoDataExchange does nt do exactly what is asked for.
Originally posted by gstercken
In addition, it does other useful things, like restoring the focus and the selection to the control where the input has to be corrected. When overriding OnOK, those things had to be implemented manually, too.
When overriding OnOK, a custom error message can be provided, and restoring the focus to the control is just one line of code.
Originally posted by gstercken
Not overly complicated, of course, but it's not the designed way of doing validation, and it requires more code (an estimated 3x more).
Whose estimate?
I really think that not everyone agrees that DDV is the only solution.
Originally posted by gstercken
As already mentioned, it is unsafe towards further extensions. When changing the dialog to modeless or to a property sheet, the validation code implemented in OnOK would have to be modified, copied or moved. Failing to remember that would lead to subtle errors (like the validation taking place when clicking OK, but not when clicking Apply and then Cancel, or when switching to a different property page.)
These are all typical consequences of making modifications to software. There are many things that can be overlooked if a person does not know what to do or if they simply overlook something. It happens. However the modifications relevant here would not be required when converting to modeless; other changes would definitely be required. I don't know what the changes would be required when converting to a property sheet, but I suspect that other changes would be substantial.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|