General Question ... Class & Members
in [MFC]
|
From: JCO on 5 May 2010 15:23 I have a general question concerning members of class and assigning the content. Particularly if I have a class that, for instance has an EditBox. If I use the Wizard, I can create a member data of type "Control" or "Variable". If I choose variable, the wizard does it's thing. Is this variable simply used as a conduit? Should it be used simply to set my actual data member that I created manually in my Class? Example. m_editClientName was created from the Wizard as type variable CString. m_strClientName was created by me as part of my private class member. Code: UpdateData(true); m_strClientName = m_editClientName; //editbox variable is simply a conduit to set my my actual member I'm asking the question because sometimes I fill like I'm creating more data variables than really needs to be. So, is it good practice to do it the way shown above? In reality (I just didn't show it), my data is private and I use Public "Get" & "Set" statements to get & set the variables. So below is the way I've been doing it. Code: UpdateData(true); SetClientsName( m_editClientName ); Continued Code: MyClass::SetClientsName ( CString strName ) { m_strClentName = strName; } Thanks for your response.
From: David Ching on 5 May 2010 16:12 "JCO" <someone(a)somewhere.com> wrote in message news:eIhWOjI7KHA.604(a)TK2MSFTNGP05.phx.gbl... > Example. > m_editClientName was created from the Wizard as type variable CString. > m_strClientName was created by me as part of my private class member. > > Code: > UpdateData(true); > m_strClientName = m_editClientName; //editbox variable is simply a > conduit to set my my actual member > > I'm asking the question because sometimes I fill like I'm creating more > data variables than really needs to be. So, is it good practice to do it > the way shown above? m_strClientName is redundant. Just use m_editClientName. This is the advantage of using DDX member variables, and aside from the fact that Joe doesn't like them, they do work well in normal cases. The only time to avoid them is if you have to do UpdateData(FALSE) at a time which would incorrectly overwrite the control value. -- David
From: David Lowndes on 5 May 2010 17:49 >I have a general question concerning members of class and assigning the >content. Particularly if I have a class that, for instance has an EditBox. >If I use the Wizard, I can create a member data of type "Control" or >"Variable". If I choose variable, the wizard does it's thing. Is this >variable simply used as a conduit? Should it be used simply to set my >actual data member that I created manually in my Class? Example. >m_editClientName was created from the Wizard as type variable CString. >m_strClientName was created by me as part of my private class member. You usually only need to use the variable created by the Wizard - you can give it your own name of course, and make it private (and have your own public accessor methods) if that's what you want. Dave
From: JCO on 5 May 2010 18:01 That is one of my concerns. You use the UpdateData() many times in an application. Also, you seem to loose the encapsulation. If done the way you both say is okay, the EventChange method would only contain the one single line of code.... UpdateData(true). This sets the member data. "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:A4EC783D-85C7-43BC-92F0-1BD070B04EC6(a)microsoft.com... > "JCO" <someone(a)somewhere.com> wrote in message > news:eIhWOjI7KHA.604(a)TK2MSFTNGP05.phx.gbl... >> Example. >> m_editClientName was created from the Wizard as type variable CString. >> m_strClientName was created by me as part of my private class member. >> >> Code: >> UpdateData(true); >> m_strClientName = m_editClientName; //editbox variable is simply a >> conduit to set my my actual member >> >> I'm asking the question because sometimes I fill like I'm creating more >> data variables than really needs to be. So, is it good practice to do it >> the way shown above? > > m_strClientName is redundant. Just use m_editClientName. This is the > advantage of using DDX member variables, and aside from the fact that Joe > doesn't like them, they do work well in normal cases. The only time to > avoid them is if you have to do UpdateData(FALSE) at a time which would > incorrectly overwrite the control value. > > -- David > > >
From: Joseph M. Newcomer on 5 May 2010 21:05
I am always offering a contrarian opinion on this: I would NEVER, EVER use a variable to hold a value except in some extremely rare and estoteric situations which I hardly ever encounter, so NEVER, EVER is a pretty good characterization of what I do. 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. 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. I generally react to code that arrives on my desk by removing all these variables and removing all UpdateData calls, and replacing them with what I consider sane and robust code. I allow ONLY control variables to exist. On Wed, 5 May 2010 14:23:35 -0500, "JCO" <someone(a)somewhere.com> wrote: >I have a general question concerning members of class and assigning the >content. Particularly if I have a class that, for instance has an EditBox. >If I use the Wizard, I can create a member data of type "Control" or >"Variable". If I choose variable, the wizard does it's thing. Is this >variable simply used as a conduit? Should it be used simply to set my >actual data member that I created manually in my Class? Example. >m_editClientName was created from the Wizard as type variable CString. >m_strClientName was created by me as part of my private class member. > >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) ***** >m_strClientName = m_editClientName; //editbox variable is simply a >conduit to set my my actual member **** I would use m_EditClient.GetWIndowText(m_strClientName); which makes it obvious what is going on; there is never a chance that the variables and the controls are out-of-sync. There is only one truth, the truth in the control. Note that because I rely on the truth of the control, there is never a need to have the string value kept in a member variable at all! In fact, it is not at all clear why you wrote the equivalent of B = A: above, because A already has the value and there is no reason to make a copy of it in B! ***** > >I'm asking the question because sometimes I fill like I'm creating more data >variables than really needs to be. So, is it good practice to do it the way >shown above? In reality (I just didn't show it), my data is private and I >use Public "Get" & "Set" statements to get & set the variables. So below is >the way I've been doing it. **** My opinion: if you have n data variables, you have n-too-many variables. **** > >Code: >UpdateData(true); >SetClientsName( m_editClientName ); **** It is not clear why you need to do this inside the implementation. Not that it is bad, but if the whole point is to copy a private value to a public value, there are serious questions that should be asked, such as why there is even a private copy at all. > >Continued Code: >MyClass::SetClientsName ( CString strName ) >{ > m_strClentName = strName; >} **** What good does it do to set this name in a variable if the variable is not transferred to the control? The whole point of using a setter is that it should actually do something to make this internal copy be the control contents, or the control and the copy are out-of-sync and if the user types something we are going to have problems. Note that doing this right is not always easy or straightforward, but doing it wrong (UpdateData) is really easy and supported by the framework; so it is easy to get wrong. 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. We really need to have dialogs support the OnUpdateCommandUI mechanism; but I essentially do that explicitly with my constraint-based model (see my essay on dialog control management on my MVP Tips site) joe **** > >Thanks for your response. > > > > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |