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.
Printable View
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