DDX contol type question
in [MFC]
|
From: RB on 17 Feb 2010 21:20 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. 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 ? 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. 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. But why would it make a variable inside a function jump outside the function to another class declaration of the same name. 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 }
From: Tom Serface on 17 Feb 2010 23:46 Did you try deleting the .ncb file and recompiling to see if it's just an intellisense problem? Tom "RB" <NoMail(a)NoSpam> wrote in message news:uukF$DEsKHA.4220(a)TK2MSFTNGP05.phx.gbl... > 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. 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 ? > 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. > 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. But why would it make > a variable inside a function jump outside the function to another class > declaration > of the same name. 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 > } >
From: RB on 18 Feb 2010 10:00 Hopefully I have worded this clearly, all of the class relevance (being parent window owner class, and also base class of derived owner draw class) is somewhat elongatingly confusing. Yes, I did delete the ncb file but did not help and what is even more strange is the problem variables are defined (and declared ) locally inside separate functions (each inside a separate class). The only tie is the fact that the derived class (of the base class CListBox) is the "type" of control variable declared in the class wizard so that it will "associate" (not sure it that's the right word ) or "link to" the DrawItem function inside said derived class with the ListBox created in my FormView class. I think it now just a broswer issue though since even though the browser still jumps to the FormView class when checking the variable in the DerivedList class, the compile does produce the following error when I comment out all references to the variable in the DerivedList class. : warning C4101: 'nIndex' : unreferenced local variable so obviously the compiler can see the variable is local to DrawItem (and now not referenced ) but the browser is still confused. My debugger seems to show what one should correctly expect now (although earlier I thought different but might have been confused trying to sort it all out) Here the debugging screens show the first values reflect the coming into the CListBoxDerived::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct) function. The " nIndex " is the problem variable name spoke of. I took out all references to it inside the DrawItem function but left it declared there for diagnostics. For the code to function I replace all references in the DrawItem function with another variable declared "only" inside the DrawItem func which is ItemIndex. Here is the lead in source code of the DrawItem func CDC dc; // declare CDC class object CRect rcItem(lpDrawItemStruct->rcItem); // create CRect and construct with func parameter passed values UINT nIndex ; // old problem variable with same name as one in other class UINT ItemIndex = lpDrawItemStruct->itemID; // new replacement variable (not same name) Now here is the debugger outputs the old nIndex variable with the same random value as the value in the new ItemIndex (so this is good, as it should be) + rcItem {top=0 bottom=16 left=0 right=683} nIndex 3435973836 // (CC CC CC CC hex) random garbage coming in so that is as should be ItemIndex 3435973836 lpDrawItemStruct->itemID 4294967295 // value destined for the index variable + dc {hDC=0x00000000 attrib=0x00000000} + lpDrawItemStruct->hDC 0x06010928 // etc code -----------------------------So basically it now looks like a browser issue only ? I guess I will try to delete my browser file and recreate it. Wondering if anyone else has had anything like this happen ? All of this owner draw stuff is a mess but I have not been able to find any other way to customize my FormView's resource editor's Listbox. There does not appear to be anyway to directly alter the default DrawItem function in the FormView's class (the parent of the Listbox). ---message thread--------------------- "Tom Serface" <tserface(a)msn.com> wrote in message news:eGOYlVFsKHA.5356(a)TK2MSFTNGP02.phx.gbl... > Did you try deleting the .ncb file and recompiling to see if it's just an intellisense problem? > > Tom > > "RB" <NoMail(a)NoSpam> wrote in message news:uukF$DEsKHA.4220(a)TK2MSFTNGP05.phx.gbl... >> 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. 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 ? >> 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. >> 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. But why would it make >> a variable inside a function jump outside the function to another class declaration >> of the same name. 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 >> } >> > >
From: Tom Serface on 19 Feb 2010 00:20 I've never see that kind of behavior, but I think those values in the debug build for an uninitialized variable are pretty normal. Still, it looks like you are initializing at least one of the viables so ... strange. I hope you got it worked out. Tom "RB" <NoMail(a)NoSpam> wrote in message news:%23YKPpsKsKHA.5940(a)TK2MSFTNGP02.phx.gbl... > Hopefully I have worded this clearly, all of the class relevance (being > parent window owner class, > and also base class of derived owner draw class) is somewhat elongatingly > confusing. > Yes, I did delete the ncb file but did not help and what is even more > strange is the problem variables > are defined (and declared ) locally inside separate functions (each inside > a separate class). > The only tie is the fact that the derived class (of the base class > CListBox) is the "type" of control variable > declared in the class wizard so that it will "associate" (not sure it > that's the right word ) or "link to" the > DrawItem function inside said derived class with the ListBox created in my > FormView class. > I think it now just a broswer issue though since even though the browser > still jumps to the FormView > class when checking the variable in the DerivedList class, the compile > does produce the following error > when I comment out all references to the variable in the DerivedList > class. > : warning C4101: 'nIndex' : unreferenced local variable so > obviously the compiler can see > the variable is local to DrawItem (and now not referenced ) but the > browser is still confused. > My debugger seems to show what one should correctly expect now (although > earlier I thought different > but might have been confused trying to sort it all out) Here the debugging > screens show the first values > reflect the coming into the CListBoxDerived::DrawItem(LPDRAWITEMSTRUCT > lpDrawItemStruct) > function. The " nIndex " is the problem variable name spoke of. I took > out all references to it inside the > DrawItem function but left it declared there for diagnostics. For the > code to function I replace all > references in the DrawItem function with another variable declared "only" > inside the DrawItem func > which is ItemIndex. > Here is the lead in source code of the DrawItem func > > CDC dc; // declare CDC class object > CRect rcItem(lpDrawItemStruct->rcItem); // create CRect and construct > with func parameter passed values > UINT nIndex ; // old problem variable with same name as one in > other class > UINT ItemIndex = lpDrawItemStruct->itemID; // new replacement > variable (not same name) > > Now here is the debugger outputs > the old nIndex variable with the same random value as the value in the new > ItemIndex (so this is good, > as it should be) > > + rcItem {top=0 bottom=16 left=0 right=683} > nIndex 3435973836 // (CC CC CC CC hex) random garbage coming in so > that is as should be > ItemIndex 3435973836 > lpDrawItemStruct->itemID 4294967295 // value destined for the index > variable > + dc {hDC=0x00000000 attrib=0x00000000} > + lpDrawItemStruct->hDC 0x06010928 // etc code > -----------------------------So basically it now looks like a browser > issue only ? I guess I will > try to delete my browser file and recreate it. Wondering if anyone else > has had anything like this > happen ? > All of this owner draw stuff is a mess but I have not been able to find > any other way to customize my > FormView's resource editor's Listbox. There does not appear to be anyway > to directly alter the > default DrawItem function in the FormView's class (the parent of the > Listbox). >
From: Joseph M. Newcomer on 20 Feb 2010 01:02
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 |