General Question ... Class & Members
in [MFC]
|
From: David Ching on 5 May 2010 21:25 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:1i44u59hf7o13rrovvkbd5lfgd8fo0q0ke(a)4ax.com... >>Code: >>UpdateData(true); > **** > You can tell this was designed by an amateur because UpdateData takes an > argument, true or > false, to indicate the direction of flow. If anything resembling > intelligent design was > used, there would have been methods called ControlsToVariables and > VariablesToControls, > instead of the non-mnemonic 'true' and 'false' options of UpdateData. You > can always tell > bad design because it exhibits pathologies like this. I never liked it > when I first > encountered it, because I had already spent over two decades arguing > against this kind of > design (it is hard to use, highly error-prone, and basically sucks) I'm usually among the most dense people in terms of analyzing the name of something and figuring out what it does, but in this case, I think UpdateData(BOOL) makes intuitive sense! Think of it as Update(Member)Data. If it is TRUE, it is as the name means -- the member data is updated. If it is FALSE, it is the opposite of the name -- the HWND gets the member data. > None of my dialogs have ever been so trivial as to be able to use > UpdateData. For > example, I want to enable the Dothis button when the edit control is > non-empty. UpdateData > doesn't have any provision for this. > It works for me. Handle EN_CHANGE: UpdateData(); // (with no parameter, TRUE is assumed m_buttonDoThis.EnableWindow( m_strClientName.GetLength() > 0 ); I like DDX because it lets you write 2 line handlers like the above that make it really easy to even leave out the comment // Enable Do This button if something is typed into the edit box I mean it reads like that already. Convolute the code with all manner of temporary CString, GetWindowText, DDX control variable access etc. and you will find yourself adding the comment. -- David
From: David Scambler on 5 May 2010 21:55 > > It works for me. Handle EN_CHANGE: > > UpdateData(); // (with no parameter, TRUE is assumed > m_buttonDoThis.EnableWindow( m_strClientName.GetLength() > 0 ); > > I like DDX because it lets you write 2 line handlers like the above > that make it really easy to even leave out the comment > > // Enable Do This button if something is typed into the edit box > > I mean it reads like that already. Convolute the code with all manner > of temporary CString, GetWindowText, DDX control variable access etc. > and you will find yourself adding the comment. > > -- David > > A word in defence of Joe's methodology. (Not that he can't defend himself !) I used to write code exactly like these 2 line handlers, and still do occasionally. But inevitably the program gets changed then changed again and you find yourself making multiple fixes to get the controls behaving consistently. Since adopting Joe's advice for any serious development, I find it easier to keep track of all the controls and their states, especially since any EnableWindow() etc. would usually be in a single method that ensures consistency.
From: Goran on 6 May 2010 02:24 On May 6, 3:25 am, "David Ching" <d...(a)remove-this.dcsoft.com> wrote: > > None of my dialogs have ever been so trivial as to be able to use > > UpdateData. For > > example, I want to enable the Dothis button when the edit control is > > non-empty. UpdateData > > doesn't have any provision for this. > > It works for me. Handle EN_CHANGE: > > UpdateData(); // (with no parameter, TRUE is assumed > m_buttonDoThis.EnableWindow( m_strClientName.GetLength() > 0 ); While I also disagree with Joe on general usefulness of DDX, systematically calling UpdateData is sometimes way too coarse-grained. It transfers ALL dialog control state to ALL dialog members, and that might, or might not, be desirable. I am convinced that many-a-MFC-er encountered situations where calling UpdateData was causing problems. Goran.
From: Oliver Regenfelder on 6 May 2010 03:32 Hello, Joseph M. Newcomer wrote: > I make all the variables "control" variables which are just ways to name the control, and > use methods of those variables to extract the data from the control, such as > GetWindowText, GetCheck, GetCurSel, etc. If I call SetWindowText (or any other method) on a control variable, do I then still need to call UpdateData(FALSE) or do control variables immediately update the control? > I never, ever call UpdateData in a dialog or formview; I think the ONLY valid times this > is called is when the framework calls them before OnInitDialog or after OnOK is called, > and 99% of the time, I never use this capability either. I seriously preach that the > whole DDX mechanism should not be used, EXCEPT for DDX_Control that binds controls to > variables, and the entire DDV mechanism should be ignored completely, in favor of > intelligent real-time input validation. How would you go about this matters in a Dialog Based application. Because there is typically no OnOk or whatever as in a modal dialog, but you just have to interact with the user on whichever control he uses. Best regards, Oliver
From: David Ching on 6 May 2010 10:27
"Goran" <goran.pusic(a)gmail.com> wrote in message news:66615a25-f9df-42a8-86ed-274ad556302d(a)k29g2000yqh.googlegroups.com... > While I also disagree with Joe on general usefulness of DDX, > systematically calling UpdateData is sometimes way too coarse-grained. > It transfers ALL dialog control state to ALL dialog members, and that > might, or might not, be desirable. I am convinced that many-a-MFC-er > encountered situations where calling UpdateData was causing problems. > It's true, eventually you will discover UpdateData() problems with coarseness, as you try to do more and more sophisticated things. But this does not negate that it is a useful technique for more situations than not, like a lot of things in C++ like casting, multiple inheritance, and other controversial things. -- David |