DDX contol type question
in [MFC]
|
From: RB on 20 Feb 2010 18:55 Thanks for the detailed data at the end, that was very informative. I have since found that an #include DerivedClass in the header of the Class that DerivedClass is a member of is the culprit of the F-12 Foobar. The debugger data was an errant observation on my part, after sorting it all out I found the debugger was showing correct data. "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:hvtun5dbraqvoeacu7drklus4ad0nuolb8(a)4ax.com... > See below... > On Wed, 17 Feb 2010 21:20:48 -0500, "RB" <NoMail(a)NoSpam> wrote: > >>Greatly appreciate anyone showing me what I'm missing here. >>My ViewClass holds my resource editor ListBox and is the parent class. >>DerivedClass (from CListBox base class) holds my owner draw DrawItem function. >> I don't really yet understand everything about this but I wrote my first >>OwnerDraw derived CListBox class for the DrawItem Function to change >>the text in my VC studio resource editor created ListBox. >> Well the code compiled with no errors but in my debugger I noticed that >>this one UINT in my DrawItem function, going in was already initialized with >>a value that it should not have. > **** > I presume that value was describable. WHat was it? > **** >> So I checked it's definition with the code >>browser (F12 key) and to my surprise the browser jumped to Parent window >>class of the ListBox instead of the UINT inside the DrawItem function ? > **** > Well, that doesn't matter too much. Trusting something like F12 to always do the right > thing is probably misplaced. You didn't say what "it's" refers to, so if you mean the > definition of a value, you have to tell us exactly what is going on. I don't derive any > information from your description that says what you did, or what you were looking at. > **** >> When I say Parent class I don't mean the Base class of my derived class but >>rather the Parent class of the resource editor ListBox which is the owner of the >>ListBox that I wrote the derived class to hold the DrawItem function. > **** > Actually, this may even be correct behavior. You haven't made it clear what value you > were looking at, or what you saw. Makes it hard to guess. > ***** >> Obviously to get the message pump to call my derived class's DrawItem function >>I had to make the ListBox's Class Wizard's control variable of the derived class's type. >>And then having done that I had to #include my derived CListBox's class header file in the >>Parent Class's header file to compile with errors. > **** > THis is both correct in analysis, and represents correct practice. > **** >>But why would it make >>a variable inside a function jump outside the function to another class declaration >>of the same name. > **** > I could not begin to tell you how often the F12 key has produced wrong results for me. > There are serious problems with it. You did not say which version of VS you are using, > but most versions < 2008 have problems. The Add Variable and Add Event Handler > mechanisms, which use the same database, have deeper problems if you have two dialogs in > two different subprojects of the same solution. > **** >>Code is shown below. The nIndex (from the code browser) jumps >>to it's definition being in the parent View class where it is also declared as int nIndex. >>Usually in a case like this my code browser will pop up a message box with two >>choices saying Resolve ambiguity. But this time it just jumps to the parent class >>definition ? >>void CListBoxDerived::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct) >>{ >> UINT nIndex; >> //etc etc > **** > Since I have no idea (a) what "etc etc" means or (b) what value you saw, it is hard to > guess what is going on. But the problem, of variables having similar names, is not > uncommon with F12. It really doesn't understand scopes properly. Even the debugger > sometimes displays the wrong result, depending on where you have a breakpoint set. For > example, > > class myclass { > int nIndex; > ... stuff > }; > > > void myclass::function(...) > { > int nIndex = 0; > ...stuff > { > int nIndex = 1; > .... > } > > ... more stuff > { > int nIndex = 2; > .... > } > } > > pretty much doesn't work under most versions of VS. The debugger will fasten on one of > the values, no matter where the breakpoint is. Usually the wrong one. > > The general solution is that you should not have a variable named in the class overridden > by a local name, which is one of the reasons the m_ notation is favored by a number of > people. It enforces a namespace partitioning where all class-level names are distinct > from all local variables, and there are reasons beyond sane debugging this can be > valuable. But as soon as you have global variables or class-member variables names > overridden by local variables, you should not be surprised at all to see these kinds of > errors. Perhaps the forthcoming VS2010 fixes this, but I haven't downloaded it yet so > don't know if it has. > joe > **** >>} >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |