C#

Andy_L_J wrote:

some of the constructs are a little confusing!

public event PropertyChangedEventHandler PropertyChanged;

protected virtual void OnPropertyChanged(string propertyName)
{
  if (this.PropertyChanged != null)
  {
    PropertyChanged(this, new PropertyChangedEventArgs(PropertyName));
  }
}

OriginalGriff wrote:

at least there is a clear distinction between a method call and an index!

1. The method signature. There is nothing wrong with what you have, but normally (in non WPF) the EventArgs instance is passed as a parameter:
   
   C#

   protected virtual void OnPropertyChanged(PropertyChangedEventArgs e)

   This is of no consequence as your code will function exactly the same, but I thought I'd mention it.
2. This is more important. There is a potential race condition with your null test. It is possible that PropertyChanged could become null between the check and you calling it. I have seen this too in much WPF code, so maybe there is some internal locking or something going on behind the scenes in WPF. The normal way would be to create a copy and call the copy:
   
   C#

   PropertyChangedEventHandler eh = PropertyChanged;
   if(eh != null)
   {
       eh(...);
   }

   
   

public event PropertyChangedEventHandler PropertyChanged;
 
protected virtual void OnPropertyChanged(PropertyChangedEventArgs e)
{
    PropertyChangedEventHandler eh = PropertyChanged;
    if(eh != null)
        eh(this, e);
}

DaveyM69 wrote:

if(eh != null)
eh(this, e);

Blake Miller wrote:

Under what conditions might the relative speed vary?

• strings are reference-types, and atomic in memory
  
• Converting them both before the comparison is slower than comparing them directly (there can be only one!)
  
• Microsoft "advises" to use uppercase constants. Has something to do with efficiency in comparing.
  
• Does it matter?
  

Many string operations, most important the Compare and Equals methods, now provide an overload that accepts a StringComparision enumeration value as a parameter.

When you specify either StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase, the string comparison will be non-linguistic. That is, the features that are specific to the natural language are ignored when making comparison decisions. This means the decisions are based on simple byte comparisons and ignore casing or equivalence tables that are parameterized by culture. As a result, by explicitly setting the parameter to either the StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase, your code often gains speed, increases correctness, and becomes more reliable.

Bastard Programmer from Hell
if you can't read my code, try converting it here[^]

Blake Miller wrote:

It does matter. I am looking into this because customers are complaining about
CPU load.

int ITERATIONS = 1000000;

string s1 = "Hello World";
string s2 = "hello world";

Debug.Assert(s1.ToLower() == s2.ToLower());
Debug.Assert(string.Compare(s1, s2, true) == 0);

var sw1 = new Stopwatch();
sw1.Start();
for (int i = 0; i < ITERATIONS; i++)
{
   Debug.Assert(s1.ToLower() == s2.ToLower());
}
sw1.Stop();

var sw2 = new Stopwatch();
sw2.Start();
for (int i = 0; i < ITERATIONS; i++)
{
   Debug.Assert(string.Compare(s1, s2, true) == 0);
}
sw2.Stop();


Console.WriteLine("ToLower: {0}", sw1.Elapsed);
Console.WriteLine("Compare: {0}", sw2.Elapsed);

ToLower: 00:00:00.4507542
Compare: 00:00:00.1856049