I'm working on an existing class that is two steps derived from System.Windows.Forms.Combo box.
The class overrides the Text property thus:
public override string Text
{
get
{
return this.AccessibilityObject.Value;
}
set
{
if (base.Text != value)
{
base.Text = value;
}
}
}
The reason given for that "get" is this MS bug: http://support.microsoft.com/kb/814346
However, I'm more interested in the fact that the "if" doesn't work.
There are times where "base.Text != value" is true and yet pressing F10 steps straight to the closing } of the "set" and the Text property is not changed.
I've seen this both by just checking values in the debugger, and putting a conditional breakpoint on that only breaks when the "if" statement's predicate is true.
How on earth can "if" go wrong?
The class between this and ComboBox doesn't touch the Text property. The bug above shouldn't really be affecting anything - it says it's fixed in VS2005. Is the debugger showing different values than the program itself sees?
Update
I think I've found what is happening here.
The debugger is reporting value incorrectly (including evaluating conditional breakpoints incorrectly). To see this, try the following pair of classes:
class MyBase
{
virtual public string Text
{
get
{
return "BaseText";
}
}
}
class MyDerived : MyBase
{
public override string Text
{
get
{
string test = base.Text;
return "DerivedText";
}
}
}
Put a breakpoint on the last return statement, then run the code and access that property.
In my VS2005, hovering over base.Text gives the value "DerivedText", but the variable test has been correctly set to "BaseText".
So, new question: why does the debugger not handle base properly, and how can I get it to?
