General Question ... Class & Members
in [MFC]
|
From: Joseph M. Newcomer on 6 May 2010 22:22 See below... On Thu, 6 May 2010 14:52:08 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:bic6u5dsrf3lkvet7graoap8c5v4gm5ucj(a)4ax.com... >> The problem is that in sophisticated tests, you want to enable the button >> if the text is >> nonempty and the whatever checkbox is checked, so it becomes >> >> m_ButtonDoThis.EnableWIndow(m_strCleintName.GetLength() > 0 && >> m_chkWhatever.GetCheck() == BST_CHECKED); >> >> and then you have to replicate this in the OnBnClicked handler, and >> then...anyway, in one >> of the classics, I found something like 23 different locations where code >> like this >> appeared, using six different algorithms, only two of which were correct. >> So the >> complaint was "the controls enable and disable incorrectly, and it depends >> on what order >> you click or type things so we have to tell the customers the correct >> order to use, and >> this is incorrect". >> >> While any one instance in a contrived example might look simple, in real >> dialogs it often >> becomes much more confusing to manage this. > >In real dialogs of that complexity, both the EN_CHANGE and BN_CHECKED >handlers would call the same function which would be the same lines. >Nothing you have said here invalidates using UpdateData. In fact, using >control variables does not simplify the problem in any way. **** (a) I agree, and in fact that is how I do it; my method is called updateControls() and its call is sometimes the entire body of one of these handlers (b) Since I usually need the control variables, it is not clear why I need a duplicate set of semi-useless data variables as well. Note that there is no value to knowing the index in a listbox or combobox, and there is no way to handle controls other than the trivial subset that DDX can handle, so there is rarely any advantage to being able to "easily" get a subset of the values I care about, given how cheap it is to get what I need. I didn't say it "invalidates" the use, I merely said that I consider it poor style because it grabs values that don't matter from a subset of the controls. **** > > >> If you replace the UpdateData() with >> CString s; >> m_ctlClientName.GetWindowText(s); >> you have added only one line, a declaration of a variable, and not >> required accessing any >> value OTHER than the one actually required. > >After getting used to WinForms which allows: > > m_ButtonDoThis.Enabled = (m_strCleintName.Length > 0) && >m_chkWhatever.Checked; > >I tend to write my MFC code to emulate it as closely as possible. You lose >your tolerance of superfluous temporary variables and other nonsense. > > >> I have found that it is easier to manage the controls if all the >> management is in one >> place, particularly when more than one condition is involved in the >> enable/visible state. > >I agree, but that has nothing to do with using UpdateData() or not. > >-- 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 7 May 2010 00:51 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:9rt6u5hppufdl3j4k8f49ntb1n4uh9v96c(a)4ax.com... > And how many times do we ask people "have you entered the debugger and > single-stepped?" > only to be responded to by the NG equivalent of a blank look? > > What you and I can do easily doesn't count. And ultimately, I get to try > to fix the mess > they create. I know this, because I have not once received a piece of > code that did not > have masses of "code clumps" that were created by copy-and-paste (which is > the editor > solution to a subroutine call!). And which were ultimately wrong, and > unmaintainable. I fail to understand why I need to code so that others have less chance to screw it up. As I said, the solution is to let them write Excel macros instead of MFC programs. This is the same thing as saying no one should use pointer arithmetic because it's easy to screw up. -- David
From: David Ching on 7 May 2010 00:54 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:o4u6u5h3fced06u4tr4nmflke0svlblkpd(a)4ax.com... > (b) Since I usually need the control variables, it is not clear why I need > a duplicate set > of semi-useless data variables as well. Note that there is no value to > knowing the index > in a listbox or combobox, and there is no way to handle controls other > than the trivial > subset that DDX can handle, so there is rarely any advantage to being able > to "easily" get > a subset of the values I care about, given how cheap it is to get what I > need. I didn't > say it "invalidates" the use, I merely said that I consider it poor style > because it grabs > values that don't matter from a subset of the controls. It handles nicely text from edit boxes which the example started with. As for the checkbox, I thought you could easily assign it's checked value to a BOOL DDX variable, but perhaps not if it is tri-state. Even if DDX handles only a subset of controls, what it does handle is welcome relief. -- David
From: Joseph M. Newcomer on 7 May 2010 03:59 It is not that others screw up YOUR code; it is a question of creating code that cannot be screwed up by nominally orthogonal changes. While it would be nice to shuffle these people off to harmless activities like Excel macros, the sad truth is that the companies they work for don't need Excel macros, but need MFC solutions. So we need to teach them how to do the work in a robust fashion. One of my mantras for several decades (three or four) has been "robust under maintenanance", which means making it fairly obvious how to make changes. As I tell some of my classes, "Remember, your code will be maintained by unskilled labor. This means the 'new hire' or yourself, six months later". I've had the experience of getting code back from clients YEARS (five) after I delivered it ("We just added a new feature to our controllers, and figured you could add support for it faster than anyone here"), and discovered that I'm that "unskilled labor" and I had to depend on the fact that I had left seriously useful comments in the original code. The Good News is that I had actually done that, and adding features did not require worrying about finding the 23 places I had duplicated the code, but had concentrated it in a set of easily-maintained functions that were actually orthogonal and could be maintained independently. Most of the code I write is going to be maintained by people vastly less skilled than I am, and I have to deliver not just *working* code, but *maintainable* code. joe On Thu, 6 May 2010 21:51:27 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:9rt6u5hppufdl3j4k8f49ntb1n4uh9v96c(a)4ax.com... >> And how many times do we ask people "have you entered the debugger and >> single-stepped?" >> only to be responded to by the NG equivalent of a blank look? >> >> What you and I can do easily doesn't count. And ultimately, I get to try >> to fix the mess >> they create. I know this, because I have not once received a piece of >> code that did not >> have masses of "code clumps" that were created by copy-and-paste (which is >> the editor >> solution to a subroutine call!). And which were ultimately wrong, and >> unmaintainable. > >I fail to understand why I need to code so that others have less chance to >screw it up. As I said, the solution is to let them write Excel macros >instead of MFC programs. This is the same thing as saying no one should use >pointer arithmetic because it's easy to screw up. > >-- 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 7 May 2010 04:01
See below... On Thu, 6 May 2010 21:54:40 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:o4u6u5h3fced06u4tr4nmflke0svlblkpd(a)4ax.com... >> (b) Since I usually need the control variables, it is not clear why I need >> a duplicate set >> of semi-useless data variables as well. Note that there is no value to >> knowing the index >> in a listbox or combobox, and there is no way to handle controls other >> than the trivial >> subset that DDX can handle, so there is rarely any advantage to being able >> to "easily" get >> a subset of the values I care about, given how cheap it is to get what I >> need. I didn't >> say it "invalidates" the use, I merely said that I consider it poor style >> because it grabs >> values that don't matter from a subset of the controls. > >It handles nicely text from edit boxes which the example started with. As >for the checkbox, I thought you could easily assign it's checked value to a >BOOL DDX variable, but perhaps not if it is tri-state. Even if DDX handles >only a subset of controls, what it does handle is welcome relief. **** Actually, I don't see the "relief" at all. I have to maintain a set of duplicate variables, that may or may not reflect the instantaneous contents of the controls, and I have to use a non-intuitive mechanism to grab them (does "true" transfer TO or FROM the controls?). It is easier just to ask the control I need what its value is. 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 |