Printable View
Please stay with the topic at hand. The issue here is whether or not to implement the datacheck OnOk() or DoDataExchange(). As I have mentioned before based on what has been said about DoDataExchange().
For this particular problem, the DoDataExchange() solution is not more efficient that OnOk().
Kuphryn
If you don't know what you're talking about, please don't post. You are wrong, and I'm sorry you don't see that. Play with it a bit and you'll see.Quote:
Originally posted by kuphryn
Please stay with the topic at hand. The issue here is whether or not to implement the datacheck OnOk() or DoDataExchange(). As I have mentioned before based on what has been said about DoDataExchange().
For this particular problem, the DoDataExchange() solution is not more efficient that OnOk().
Kuphryn
It isn't just a question of effeciency. It's a question of standards and maintainability as well. Convention calls for DoDataExchange (which is easier to use) and other programmers will expect it to be there and will understand how it works. Easy to maintain code is way more important than you seem to give it credit for.
OK, so let me answer once again (hopefully for the last time in this thread) to some of the statements:
I said more than once that doing validation in OnOK() is of course possible, but less desirable for various reasons.Quote:
Originally posted by Sam Hobbs
You do by implication. You insist that any other solution is unacceptable
...
Again, you insist that DoDataExchange is the only acceptable solution.
...
You failed so far to show even one single advantage of doing validation in OnOK() as opposed to doing it in DoDataExchange(). In contrast, I mentioned several advantages of using DoDataExchange() (or drawbacks of using OnOK(), depending on the way you prefer to look at it).
Now I always assumed it as reasonable in terms of common sense (my mistake) that given two options A and B, A having only advantages, but no drawbacks as compared to B, that it would be obvious under any circumstances to use A. So while B still remains a possible option, it would simply be silly to choose it. It is clear that, when doing wordplay, a less workable option is still an option and can be employed, but it is simply not useful to do so. So yes, in a context of practical reasoning and common sense (which I thought we were in) the better option is indeed to be considered the only acceptable solution. But I also bent towards the more philosophical point of view (which you chose to adopt) that a less workable option is also a possible solution, in the strict sense of the word. However, any intelligent person wouldn't think twice and consider only the better solution as an acceptable solution. Note that we're not talking about a classical decision problem here where both options have advantages and drawbacks which have to be evaluated against each other. We are talking about a situation where option A has only advantages and no drawbacks as compared to B. In this case, the decision process becomes trivial.
What's so unrealistic about doing data validation in PreTranslateMessage()? It's possible, and I've seen people doing it. Someone who doesn't know about implementing OnOK() could use PreTranslateMessage() for data validation. It might be absurd, clumsy, error-prone and require a lot of additional code, but it works. So to use your own words, it is "a" way. Likewise, to a person who knows about DDX/DDV and DoDataExchange(), doing the validation in OnOK() seems equally absurd, clumsy, error-prone, and requires additional code. I would even call that approach unrealistic, to reuse that term.Quote:
Originally posted by Sam Hobbs
You are being unrealistic, which is consistent with insisting that any other solution is unacceptable.
No, I'm not implying that. Of course it is normal to override OnOK(). After all, that's why it is virtual. I only stated that it is the wrong place (or not the best place, if you like that better) to do data validation.Quote:
Originally posted by Sam Hobbs
You are implying that it is not normal to process IDOK (override OnOK).
That's not something I say, but a commonplace in software development. Errors occur, and good design tries to minimize the possibility of them occurring. It's so self-evident that I'm astonished you even question it...Quote:
Originally posted by Sam Hobbs
You are saying that a good programmer will overlook obvious changes when changing a program. I think it is matter of personal preference whether that is important.
Anyway, I fear that this discussion doesn't lead any further. It is pretty obvious by now that you (and kuphryn too) are merely defending the data-validation-in-OnOK approach for the sake of defending your initial statement, and not because there are any technical arguments in favour of that approach. You both seem to have problems admitting that you were wrong. You could have easily written something like "Sorry, I totally forgot about DoDataExchange... Of course, that's actually the place to do data validation." Likewise, kuphryn could have said "Oh, I never heard about DoDataExchange before. My apologies. Next time, I will try to inform myself better before posting an answer. You always keep learning..." What's so difficult about that? Instead, you both keep insisting - in spite of hard technical facts which stand against it - that OnOK is an equally good choice for implementing data validation. It is not. Read MSDN (especially TN026), read Prosise - and it will become obvious that DDX/DDV is not only the "official" way to do validation, but that there are also good reasons to prefer that way. Most of them have been mentioned in this thread.
I can't and I don't want to prevent you from continuing to do data validation in OnOK in your own projects. Do as you like - after all, it's your team members / code reviewers / testers / customers who will complain, not mine. But you should refrain from spreading that kind of harmful advice in a forum just because you're to proud to admit that you've been wrong.
However, I'm confident that any sensible reader of this thread (seeking advice on how to implement dialog data validation) will understand nonetheless what's going on and come to the conclusion that DoDataExchange() is the way to go, OnOK being no valid alternative.
For this particular problem, I recommend validating the string in OnOk().
Kuphryn
Yeah... And for inserting a nail, I recommend a screwdriver. Why? Just don't ask... It's simply my opinion... No need for you to understand it... :rolleyes:Quote:
Originally posted by kuphryn
For this particular problem, I recommend validating the string in OnOk().
gstercken, can you please comment on the sample code I posted? If not, then I can only assume there are no problems with the way those three samples validate data in OnOk and have chsoen to ignore them.
Difficult to say without any context information... However,Quote:
Originally posted by Sam Hobbs
gstercken, can you please comment on the sample code I posted? If not, then I can only assume there are no problems with the way those three samples validate data in OnOk and have chsoen to ignore them.
So what do those samples prove? I know, you probably pulled them from some MS sample code. You will certainly let me know which "authority" wrote them, to show me how blasphemic I was in criticizing them...
- The first sample seems to be not a standard dialog - more something like a wizard which advances to the next screen under certain conditions. It doesn't even call the base class implementation of OnOK, so it just doesn't fit into the 95% case of the "normal" modal dialog with some kind of data validation.
- The second sample checks a range of edit fields for valid numeric input, it somewhat mimics what DDV does automatically anyway, so this code is highly questionable.
- The third sample checks whether a selection has been made (probably in a combo box or a list box). This check, too, would have been better performed in DoDataExchange. Besides that, from a usability point of view, I would probaby have preselected a value instead of letting the user run into that error, avoiding the problem altogether. But it really depends on the actual problem domain.
Those samples are all from the VC 6 MFC samples provided with the VC documentation. They are the following sample\source:
MFC\general\ctrltest\custlist.cpp(151):void CCustListDlg::OnOK()
MFC\general\ctrltest\spintest.cpp(65):void CSpinEditDlg::OnOK()
MFC\advanced\speakn\speakn.cpp(137):void CSpeakNDlg::OnOK()
That's exactly what I suspected. Note that those samples are meant to illustrate some isolated, detailed aspects of MFC programming , namely techniques for implementing and using custom controls (the CTRLTEST sample) and multimedia extensions (the SPEAKN sample). That sample code is stripped down and reduced to the bare minimum (the CTRLTEST code doesn't even have a DoDataExchange() in the dialog code) and concentrates on the aspects which are to be demonstrated here. They are in no way meant to show how a real-world MFC application should be designed. Did you notice that the code is barely commented? Does this mean that we shouldn't comment our code? Furthermore, those projects lack a help file. Does this imply that a real-world application should come without online help? Certainly not. They also use hard-coded strings, but I would never use that as an argument for doing the same in actual production code. That's just sample code, meant to demonstrate certain techniques in an isolated way. It doesn't prove anything useful for this discussion.Quote:
Originally posted by Sam Hobbs
Those samples are all from the VC 6 MFC samples provided with the VC documentation. They are the following sample\source:
I have been following this thread for awhile now, and I cannot believe what I am reading.
While gstercken is trying logically present value of proper coding with GCDEF ‘s support, it just shutters against a granite wall of kuphryn and Sam.
I really do not get it guys. You are just being stubborn.
Let me reiterate:
A matter of validating data in a dialog.
As gstercken stated countless number of times, he does not eliminate any other than DDX/DDV mechanism. He simply states that this method is most feasible. It is a central point to validate data for each dialog control without any need to override anything or handling something in many different places. I could introduce data verification in OnTimer handler every 100ms, but is it practical?
I am really for MCME approach. It is approach I have decided to take many years ago and it works very well. MCME means Minimum Coding Maximum Effect. If I can get something for free from MFC framework I get it no questions asked. And using gstercken suggestion complies with this approach. PERIOD.
kuphryn, you were mistaken on several occasions as anyone of us was and you did not have problem saying that it was mistake. It is much better than insisting on giving out wrong advice.
Sam, as I have indicated before, I regard you as logical and knowledgeable person and I still do. I thought instead of insisting on proving gstercken wrong (and he is not) you could invest your time for better cause, helping others.
Why are you presenting MFC samples as the proof that you are right and others are wrong? We all know that not only M$ documentation is shady in some places but also samples may not be an illustration of the best programming techniques.
Besides in some instances you present gstercken’s statements out of context and make comments that are totally out of place.
I do not know why, but I think you (Sam) take some things too personally. Nobody is trying to prove you wrong as a person, is just an approach that is hardly acceptable. Instead either back off or admit that gstercken is right you are nitpicking.
In conclusion, how avi123 will benefit from this thread? Hey are you there?
You see you scarred avi123.
Anyone saying things like that will always have problems with me. If MFC samples are shady then MFC is shady. If MFC samples are not worth using then MFC is not worth using.Quote:
Originally posted by JohnCz
Why are you presenting MFC samples as the proof that you are right and others are wrong? We all know that not only M$ documentation is shady in some places but also samples may not be an illustration of the best programming techniques.
I truly believe that if management (such as Brad) were to take action against anything said here, it won't be anything I said.
Are you going to pop out my knee cup?Quote:
Originally posted by Sam Hobbs
Anyone saying things like that will always have problems with me.
I did not say that; that is your conclusion. Some of examples are; some of them even do not compile. Besides, your reasoning here is questionable. I do not particularly appreciate somebody putting words in my mouth.Quote:
Originally posted by Sam Hobbs
If MFC samples are shady then MFC is shady. If MFC samples are not worth using then MFC is not worth using.
What kind of action and for what? Did I in any way offend anybody? If my statement criticizing M$ documentation offended MFC I apologize. If offending MFC offends you I do apologize too. Just be reasonable.Quote:
Originally posted by Sam Hobbs
I truly believe that if management (such as Brad) were to take action against anything said here, it won't be anything I said.
- not all solutions best represent the problem domain; eg. you could do this with API interception
- it is often useful in documenting intent when working with others to do pre- and post-condition / invariance checks in a central location, as offloading to routines handling other duties can fragment the logic
- sometimes, "you're an imbecile!!" really means "could I get a hug?"
:p