General Question ... Class & Members
in [MFC]
|
From: David Ching on 11 May 2010 12:38 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:6kdhu55lgeo1l627jjl3gfd2ih5po8jpqi(a)4ax.com... > My concern is not performance, but correctness. > Now that's a laugh, you are saying DDX is not correct? That's a new one, even for you. > I typically write code at the rate of about 200 lines/hour (varies from > 170 to 230). I > base this on the number of hours I bill and the code size (excluding my > standard > libraries, which are huge and would push the averages artificially high) > > I do not seem to lose any productivity to not using DDX. That's purely speculative since you have not given any baseline or any comparison with DDX. Moreover, it's a speculation that applies only to you and not the people who will be reading and maintaining your code which is much more important. The code is written just once, yet it is read many, many times (and probably by not just you but several others). Therefore, write rate is unimportant, it's the read rate that is important. So you have offered a pure speculation that applies only to you and measures the wrong thing. -- David
From: David Ching on 11 May 2010 13:50 "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:3F52A22D-6BFC-4B3F-B943-0D303439F6C8(a)microsoft.com... > "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message > news:6kdhu55lgeo1l627jjl3gfd2ih5po8jpqi(a)4ax.com... >> My concern is not performance, but correctness. One more thing that I don't believe has yet been mentioned. DDX_Text, etc. which typically use UpdateData() are very useful to have even if UpdateData() is never called in a dialog box's message handlers. This is so that the content of e.g. edit boxes, combobox selections, etc. are retained *after the modal dialog has been dismissed*. The caller code needs to know what was selected in the dialog when OK was pressed, and the DDX variables make it convenient to store, e.g. the content of an edit box control, into a CString. Since the edit box control has been destroyed, you can no longer access it after DoModal() returns, so it is mandatory to put the value somewhere else prior to this. DDX makes it really easy, in fact it does so automatically when OK is clicked! Try matching that with DDX_Control. -- David
From: Joseph M. Newcomer on 11 May 2010 20:02 See below... On Tue, 11 May 2010 10:50:51 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message >news:3F52A22D-6BFC-4B3F-B943-0D303439F6C8(a)microsoft.com... >> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >> news:6kdhu55lgeo1l627jjl3gfd2ih5po8jpqi(a)4ax.com... >>> My concern is not performance, but correctness. > >One more thing that I don't believe has yet been mentioned. DDX_Text, etc. >which typically use UpdateData() are very useful to have even if >UpdateData() is never called in a dialog box's message handlers. This is so >that the content of e.g. edit boxes, combobox selections, etc. are retained >*after the modal dialog has been dismissed*. The caller code needs to know >what was selected in the dialog when OK was pressed, and the DDX variables >make it convenient to store, e.g. the content of an edit box control, into a >CString. Since the edit box control has been destroyed, you can no longer >access it after DoModal() returns, so it is mandatory to put the value >somewhere else prior to this. DDX makes it really easy, in fact it does so >automatically when OK is clicked! Try matching that with DDX_Control. **** Note that retaining the combo box settings after the dialog is dismissed, or thinking the variable makes sense to do the correct initial selection, indicates someone who is living in a serious fantasy. The whole scheme is about as totally useless as the preloaded combo box feature of the dialog editor. When you go for localization, combo boxes are organized typically alphabetically, making any assumption about order totally useless. Therefore, the only reliable data you can have are static controls, edit controls, and check boxes. Nothing else can be trusted. Therefore, I rarely use this capapbility. If you read what I have written in the past, I have stated that the ONLY valid UpdateData calls are tnose that happen in the MFC framework, to preload static, edit, and checkbox controls, or to deliver their values. Anything else must be handled explicitly by the programmer, because nothing can be trusted to have meaningful values. And I handle that by putting code in the OnOK method that captures what I need to capture in the way I need to capture it, and not in some whimsical fashion that is sensitive to program evolution and localization. Adding a line to get what I need is not a burden, and it makes the code more robust. joe > >-- David Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 11 May 2010 20:13 See below... On Tue, 11 May 2010 09:38:46 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:6kdhu55lgeo1l627jjl3gfd2ih5po8jpqi(a)4ax.com... >> My concern is not performance, but correctness. >> > >Now that's a laugh, you are saying DDX is not correct? That's a new one, >even for you. *** I did not say "DDX Correctness", I said "prgram correctness". The misuse of UpdateData results in programs that are erroneous because the mechanism is not used correctly. The mechanism may be correct, but if it is used incorrectly, the program is incorrect. In addition, for controls beyond static, edit and checkbox, there are problems of remaining correct under localization and program evolution. joe **** > > >> I typically write code at the rate of about 200 lines/hour (varies from >> 170 to 230). I >> base this on the number of hours I bill and the code size (excluding my >> standard >> libraries, which are huge and would push the averages artificially high) >> >> I do not seem to lose any productivity to not using DDX. > >That's purely speculative since you have not given any baseline or any >comparison with DDX. **** I agree. But my point is that I can create code whose functionality exceeds anything I can achieve with DDX with no apparent impact on my productivity. **** > Moreover, it's a speculation that applies only to you >and not the people who will be reading and maintaining your code which is >much more important. **** There is nothing obscure about getting information and delivering it back in a fashion that is maintainable under program maintenance and which is insensitive to localization. So I don't see how something simple that retrieves a value in a useful fashion can be beat by a mechanism which delivers whimsical data that cannot be trusted under evoluation or localization. **** >The code is written just once, yet it is read many, >many times (and probably by not just you but several others). Therefore, >write rate is unimportant, it's the read rate that is important. So you >have offered a pure speculation that applies only to you and measures the >wrong thing. **** There's nothing complex about getting a value. It is always obvious how the value is obtained, and why it is always correct independent of program evolution and localization. Consider the following:: If I want to return a set of values, I have a choice, for example CCheckListBox CCheckBox The way DDX works, I have to know that I have a set of 10 check boxes represented by 10 BOOL variables. If I change to CCheckListBox, I have to simulate the effects, so why not do it right and make it completely independent of the control representation? It is none of the caller's business how I choose to represent those options in controls, so I can either say "here is a DWORD with a bitmask" or "here are 10 BOOL variables" and not rely on DDX to do ANYTHING for me. Similarly, the distinction between a combo box (which must localization-independent) and a set of radio buttons should be completely invisible. DDX does not support this well. So I ignore it completely, and create control-independent representations of the information and use them in whatever way I want. Otherwise, we end up being trapped by the DDX mechanism and are forced to do things the way those mechanisms dictate. This is the same reason I despise DDV. joe **** > >-- David Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 11 May 2010 20:43
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:5mrju51mtsp5d5nvukncshptsgc9lshlum(a)4ax.com... > Note that retaining the combo box settings after the dialog is dismissed, > or thinking the > variable makes sense to do the correct initial selection, indicates > someone who is living > in a serious fantasy. The whole scheme is about as totally useless as the > preloaded combo > box feature of the dialog editor. > > When you go for localization, combo boxes are organized typically > alphabetically, making > any assumption about order totally useless. Therefore, the only reliable > data you can > have are static controls, edit controls, and check boxes. Nothing else > can be trusted. > > Therefore, I rarely use this capapbility. > Not if you use DDX_CBString which associates a CString to the combobox value. > If you read what I have written in the past, I have stated that the ONLY > valid UpdateData > calls are tnose that happen in the MFC framework, to preload static, edit, > and checkbox > controls, or to deliver their values. Anything else must be handled > explicitly by the > programmer, because nothing can be trusted to have meaningful values. > > And I handle that by putting code in the OnOK method that captures what I > need to capture > in the way I need to capture it, and not in some whimsical fashion that is > sensitive to > program evolution and localization. > > Adding a line to get what I need is not a burden, and it makes the code > more robust. UpdateData() is not whimsical, the results are very defined depending on the DDX map. Why you would want to manually add data members and initialize them in the OnOK() is beyond me, when there is a fully automatic alternative built-in. I don't know what you mean that this is not robust, if you have a test case that the DDX members are not accurately populated with the control's values after the DoModal() returns, do tell. BTW, the same argument holds true when the caller initializes the dialog's initial state prior to calling DoModal(). By initializing the DDX member variables, the results are put into the dialog controls on construction, automatically. -- David |