I have a property in a composite control that checks to see if the value has changed prior to actually setting the related private field and doing a few other things.
However, it appears that it is never evaluating the statement.
Here is the code for the property:
public T SearchCriteria
{
get
{
return mySearchCriteria;
}
set
{
if (value != mySearchCriteria)
{
mySearchCriteria = value;
EnsureChildControls();
SearchGridParser parser = SearchGridParserFactory.GetParser(this.Type);
parser.SetSearchPanelControls<T>(this.mySearchCriteria, ref mySearchParametersPanel);
GridView.PageIndex = 0;
}
}
}
I have stepped through the code, and everytime it gets to "value != mySearchCriteria" it evaluates to false and skips the code inside the if statement. In fact, it does this even when I change it to "value == mySearchCriteria".. if just completely skips it no matter how it evaluates!
What the hey?
I've tried changing the order of the arguments in the check, and also using object.Equals() but none of these changes have made any difference.
I have overridden Equals, !=, == and GetHashCode.
There are other places in the code where it uses the "==" and "!=" for these object types without a problem, so I know that my overriding is working correctly.
Problem is, this never even hits the overriden methods. I put breaks on "==", "!=", "Equals" and "GetHashCode" and none of them are being called when the "value != mySearchCriteria" statement is being evaluated.
It's like it completely skips evaluating it.
Using == between generic types is almost always a bad idea. Operators are overloaded rather than overridden, so even if there is an == operator on your actual types, the compiler won't know about it. (That means your claim that you've "overridden" ==
and !=
is already incorrect - you've overloaded those operators. You should make sure you understand the difference, as it's very important.)
When you write:
There are other places in the code where it uses the "==" and "!=" for these object types without a problem, so I know that my overriding is working correctly.
I suspect those areas aren't in generic code... they're where the compiler knows what types are being compared, so knows to use your overloads. That's very different from your generic situation, where the compiler doesn't know what to use for ==, so falls back to reference identity.
I assume you have a generic constraint of where T : class
or your code wouldn't compile at all - but it's still just going to perform a reference comparison, instead of using whatever overload is provided by the actual type of T
.
Use EqualityComparer.Default<T>.Equals(value, mySearchCriteria)
to use overridden implementations of Equals
including IEquatable<T>
.