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
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:hvtun5dbraqvoeacu7drklus4ad0nuolb8@4ax.com...
See below...
On Wed, 17 Feb 2010 21:20:48 -0500, "RB" <NoMail@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@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm