TimL on C#.NET

WinForms App Locked Up - Stack shows OnUserPreferenceChanged leading to a WaitOne after unlocking workstation

noreply@blogger.com (TimL) — Wed, 21 Oct 2009 23:25:00 +0000

Today I had an interesting bug to track down in which an application kept locking up after I locked and then unlocked my workstation. I was able to attach the debugger, do a "Break All" and then use the Thread and Call Stack windows get a trace stack. Somewhere down in the .NET framework, the Microsoft.Win32.SystemEvents.OnUserPreferenceChanged method raised the UserPreferenceChanged event, and an event handler attached to that event ultimately lead to WaitOne which was blocking indefinitely on the UI thread. The top of the callstack looked like this:


  [In a sleep, wait, or join] 
  mscorlib.dll!System.Threading.WaitHandle.WaitOne(long timeout, bool exitContext) + 0x2f bytes 
  mscorlib.dll!System.Threading.WaitHandle.WaitOne(int millisecondsTimeout, bool exitContext) + 0x25 bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle waitHandle = {System.Threading.ManualResetEvent}) + 0x77 bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control caller, System.Delegate method, object[] args, bool synchronous) + 0x393 bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Control.Invoke(System.Delegate method, object[] args) + 0x50 bytes 
  System.Windows.Forms.dll!System.Windows.Forms.WindowsFormsSynchronizationContext.Send(System.Threading.SendOrPostCallback d, object state) + 0x5f bytes 
  System.dll!Microsoft.Win32.SystemEvents.SystemEventInvokeInfo.Invoke(bool checkFinalization = true, object[] args = {object[2]}) + 0x62 bytes 
  System.dll!Microsoft.Win32.SystemEvents.RaiseEvent(bool checkFinalization = true, object key = {object}, object[] args = {object[2]}) + 0x10f bytes 
  System.dll!Microsoft.Win32.SystemEvents.OnUserPreferenceChanged(int msg, System.IntPtr wParam, System.IntPtr lParam) + 0x77 bytes 
  System.dll!Microsoft.Win32.SystemEvents.WindowProc(System.IntPtr hWnd = 9111196, int msg = 8218, System.IntPtr wParam = 47, System.IntPtr lParam = 188618224) + 0x2e0 bytes

Presumably, whatever was suppose to signal the WaitOne was also on the main UI thread, so there was a deadlock. Whatever was wrong was apparently happening deep-down in the framework, as there was nothing in the application source code that ever attached an event handler to the UserPreferenceChanged event.

After Googling for some answers, it became apparent that there was probably a threading problem somewhere in the application (as if you couldn't have assumed that one?). Apparently, all top-level controls automatically register for the UserPreferenceChanged event so that they can update themselves when the WM_SETTINGCHANGE Windows message is received to indicate that desktop properties (color, theme, etc.) have changed. And, when SystemEvents raises an event to a partiuclar event handler, it checks to see if it is already on the thread appropriate for the object receiving the event; if it is not, it Invokes over to the appropriate thread. But, if the thread onto which the event handler is invoked does not have a message pump, a lockup occurs (summarized from From kbalertz.com) because Invoke waits forever.

Even with that bit of knowledge, it became difficult to track down the problem. But, "Burn me now, or burn me later" -- I eventually deteremined that it was caused by a cross-threading issue that occurred earlier in the application; for some reason, Visual Studio did not detect it as a cross-thread exception. There was a spot in code that used a System.Timers.Timer, and the callback for the Timer was not properly marshalling calls over to the UI thread before updating some UI properties. Somehow, that cross-threading issue "in the past" affected the ability for a some control to process the UserPreferenceChanged event in the future.

InvalidOperationException - "Cross-thread operation not valid..."

noreply@blogger.com (TimL) — Wed, 07 Oct 2009 21:37:00 +0000

Most C# programmers have probably seen the infamous InvalidOperationException "Cross-thread operation not valid" exception at one time or another. When you see that, you instantly know that your code tried to access the property of a control from a thread other than the thread on which the control's window handle was created. If you recall a previous post of mine (or from MSDN), there are actually only a total of four methods and properties on a control that can be access from another thread:

InvokeRequired

Invoke()

BeginInvoke()

EndInvoke()

Novice programmers may think these cross-thread exceptions are just nuisance messages that can be ignored because they do not happen in the final release build sent to the customer. That, however, couldn't be further from the truth. Rather, you should aggressively seek them out and fix them because they can lead to all kinds of unexplained lock-ups and crashes that are difficult to diagnose. But, in order to find them you have to know when you can see them!

I use to think that cross-thread exceptions are thrown in debug builds, but not thrown in release builds. That seems to be the way it works, at first, and makes sense to me as a programmer. After all, a simple #if (DEBUG) somewhere down in framework code could easily accomplish that. But, as I have found out the hard way, it is not that simple.

Rather, my experimentation has shown that cross-thread exceptions only occur if you actually started the application from within Visual Studio. If you run a debug build of the application from outside of Visual Studio, you do not get the cross-thread exceptions even if you "attached" Visual Studio to that application via the "Debug | Attach to Process..." menu.

"To Copy or Not to Copy" delegates used to raise events

noreply@blogger.com (TimL) — Wed, 02 Sep 2009 21:14:00 +0000

There is a long-standing debate amongst C#.NET developers: When raising an event, should you copy the event delegate first or not?



public event EventHandler MyEvent;

private void OnRaiseMyEventWithoutCopy()
{
    if (MyEvent != null)
    {
        MyEvent(this, new EventArgs());
    }
}

private void OnRaiseMyEventWithCopy()
{
    EventHandler myEvent = MyEvent;
    if (myEvent != null)
    {
        myEvent(this, new EventArgs());
    }
}

In both cases, you must check to see if the event delegate is null; if you attempt to invoke a null delegate you will get a NullReferenceException. Once the last event handler has unregistered, the delegate will be null.

Interestingly, the arguments for doing it one way or another typically involve reasons for not doing it the other way:

The argument for the "with copy" case basically comes down to this: If you do not do the copy, the delegate may change to null after you did the null-check but before the delegate was invoked, and that could be bad.

The argument for the "without copy" case basically comes down to this: If you do the copy, then you might invoke an event handler that has already unregistered, and that would be bad.

Honestly, I have flip-flopped on this several times over the years. But, I currently believe it to be better to do the copy. In the tradition of saying something is better this way because it is not doing that:

1) If you do not do the copy, you still have the potential NullReferenceException issue. If .NET threw a different type of exception, then you could catch it and ignore it because it would be expected that the last handler may have unregistered before you actually invoked the delegate. But, since it throws the NullRefernceException which could easily have been thrown by one of the handlers, you should probably let that bubble out so that the code raising the event knows something bad happened.

2) Whether you do the copy or not, once the framework starts traversing down the invocation list, it's just like doing a copy anyway. If a handler unregisters for an event while the framework is traversing the list, that handler will still be called. Therefore, handlers must always be written with the understanding that it can still get called after it has been unregistered.

Since you cannot prevent issue 2, which is basically what the "without copy" way is trying to prevent, you should at least do the copy because you can prevent issue 1.

Form.Load() override never called

noreply@blogger.com (TimL) — Wed, 19 Aug 2009 18:18:00 +0000

I came across an issue today that boggled my mind for a few minutes. I had an apparently normal WinForm's Form, but the OnLoad() override was never getting called. Therefore, the Load event was never rasied.

As it turns out, there was nothing wrong with the form itself, but it was being used in an unconventional way. For some special-case reasons, the code that caused the form to be displayed was using PInvoke calls to SetWindowsPos() and ShowWindow() instead of calling the Form.Show() or Form.ShowDialog() method. Apparently, because neither Show() nor ShowDialog() was used, the OnLoad() method was never called.

My solution to this problem was to override the OnVisibleChanged() method, use a flag field to track whether the initialization code had been executed, and call the initialization code from whithin OnVisibleChanged if it had not yet been executed and Visble just changed to true. The flag, of course was then changed to true so the initialization code would not be called again if the form went invisible and then became visible again.

Use Shift+Enter to insert '\n' characters using the Visual Studio resource editor

noreply@blogger.com (TimL) — Thu, 13 Aug 2009 14:53:00 +0000

This is by no means something new. It's just something I always forget to do, and forget how to do, so I figured I would post it here so I know where to find it when I need it again.

I often use hard-coded strings for message boxes, UI strings, etc. when I initially write the code, and then go back later to add all of those hard-coded strings into resource files so that they can get localized. When adding such strings to resource files, one cannot simply cut and paste it from the source code to the resource file because of the embedded control characters.

The C# Compiler knows that when it sees "\n" in a string [ that does not start with '@' ] it should replace that two-character substring with the '\n' control character. However, the resource files are not so smart; the substring "\n" in a resource string is not converted to the '\n' control character automatically. But, you can insert a '\n' newline control character into the resource string by using Shift+Enter in the Visual Studio resource editor. (For some reason, I always want to do a Ctrl+Enter but that does not work).

Dangers of Overloading Methods in Derived Classes

noreply@blogger.com (TimL) — Wed, 10 Jun 2009 21:29:00 +0000

Like most languages, C# supports method overloading. Basically, that simply means that you are allowed to have multiple methods with the same name as long as the prototypes (method signatures) are different. In theory, the compiler chooses the "best" method based on the parameters passed into the method. And, it generally does a good job. But, if the overloaded methods are distributed across several classes derived from one another, the compiler may not always choose the method you expect!

Consider the example below.



public class BaseClass1
{
    public int MyMethod(int x)
    {
        return x - 1;
    }
}

public class DerivedClass1 : BaseClass1
{
    public int MyMethod(object obj)
    {
        return (int)obj + 1;
    }
}

DerivedClass1 dc1 = new DerivedClass1();
int x1 = 100;
int y1 = dc1.MyMethod(x1);  // y1 == 101

Given the example above, you might expect y1 to be 99 because MyMethod(int) is a better match than MyMethod(obj). But, if that is what you thought then you would be wrong. The reality is that y1 == 101 because the compiler chooses MyMethod(obj) over MyMethod(int) from the base class.

The same thing applies if the method is virtual:



public class BaseClass2
{
    public virtual int MyMethod(int x)
    {
        return x - 1;
    }
}

public class DerivedClass2 : BaseClass2
{
    public virtual int MyMethod(object obj)
    {
        return (int)obj + 1;
    }
}

DerivedClass2 dc2 = new DerivedClass2();
int x2 = 100;
int y2 = dc2.MyMethod(x2);  // y2 == 101

In the case of virtual methods above, it seems like you could override the MyMethod(int) from the base class to fix the problem. But, if that's what you think, then you would be wrong again.



public class BaseClass3
{
    public virtual int MyMethod(int x)
    {
        return x - 1;
    }
}

public class DerivedClass3 : BaseClass3
{
    public override int MyMethod(int x)
    {
        return base.MyMethod(x);
    }
        
    public virtual int MyMethod(object obj)
    {
        return (int)obj + 1;
    }
}

DerivedClass3 dc3 = new DerivedClass3();
int x3 = 100;
int y3 = dc3.MyMethod(x3);  // y3 == 101

The same applies if the method is static. Although, in the case of static methods you might have expected that because you are specifically scoping to the class name. But, on the other had, public static methods of a base class are also available as public static methods on the derived class, so you might still have expected the compiler to choose MyMethod(int) over MyMethod(object).



public class BaseClass4
{
    public static int MyMethod(int x)
    {
        return x - 1;
    }
}

public class DerivedClass4 : BaseClass4
{       
    public static int MyMethod(object obj)
    {
        return (int)obj + 1;
    }
}

int x4 = 100;
int y4 = DerivedClass4.MyMethod(x4);  // y4 == 101

I have not really found a good solution to this problem. Luckily, it does not occur often (for me) because I generally do not distribute overloaded methods across multiple class. But, if I do need to do something like that, the only solution I have found is really just a workaround: use the ref keyword to help the compiler pick the right method; since the compiler knows it has to pass the parameter both in and out, it tends to do the method selection better. Although, I would hate to have to do that because it introduces a "new danger" of allowing the method to change the value.



public class BaseClass5
{
    public virtual int MyMethod(ref int x)
    {
        return x - 1;
    }
}

public class DerivedClass5 : BaseClass5
{
    public virtual int MyMethod(ref object obj)
    {
        return (int)obj + 1;
    }
}

DerivedClass5 dc5 = new DerivedClass5();
int x5 = 100;
int y5 = dc5.MyMethod(ref x5);  // y5 == 99

Nullable Parameters in Public Interfaces

noreply@blogger.com (TimL) — Thu, 26 Mar 2009 21:25:00 +0000

As discussed in previous posts, C# now has the concept of nullable value types via the ? operator. When used correctly, they can be very useful and solve some problems. But, quite honestly, I feel that they're kind of "hackish" to use them in public methods and interfaces. In many cases, you can simply make a few quick overloads to cleanup things up a bit.

Conside, for example, a class with the following public method that uses a paremeter of type int?.



public void MyMethod(int? myParameter)
{
   ...
}

Rather than exposing that method for use by others, it could instead be made private and we could define a couple of public overloads.



public void MyMethod()
{
    MyMethod();
}

public void MyMethod(int myParameter)
{
    MyMethod(myParameter as int?);
}

private void MyMethod(int? myParameter)
{
   ...
}

That code is pretty straight forward. The only trick is to cast the parameter as a int? before calling the private overload that does all the work. If you do not do that, then you will very quickly encounter a stack overflow.

Inner Classes for Organization

noreply@blogger.com (TimL) — Wed, 25 Mar 2009 01:26:00 +0000

C#.NET allows you to define inner classes. An inner class is defined within the scope of another class. There are all kinds of cool things you can do with them. But, one of the most basic uses is to simply an inner class as an organizational container.

For example, lets say we have a class that implements the System.ComponentModel.INotifyPropertyChanged interface. That interface has a single member -- the PropertyChanged event of type PropertyChangeEventHandler. The PropertyChangedEventHandler, in turn, uses PropetyChangeEventArgs as the event arguments, and the PropertyChangedEventArgs don't tell you much except the name of the property that changed.

If our class is going to implement INotifyPropertyChanged, it also follows that we probably need to define some constants (or static readonly fields) for the various properties that may raise the PropertyChanged event.

The traditional approach would be to write a class something like the one shown below.



public class Class1a : INotifyPropertyChanged
{
    public static readonly string MyFirstPropertyName = "MyFirstProperty";
    public static readonly string MySecondPropertyName = "MySecondProperty";

    public event PropertyChangedEventHandler PropertyChanged;

    ...
}

But, there is no reason why we couldn't (and shouldn't) encaspulate those property constants into their own container via an inner class.



public class Class1b : INotifyPropertyChanged
{
    public static class PropertyNames
    {
        public static readonly string MyFirstProperty = "MyFirstProperty";
        public static readonly string MySecondProperty = "MySecondProperty";
    }

    public event PropertyChangedEventHandler PropertyChanged;

    ...
}

In the first example, the constant can be accessed with syntax like Class1a.MyFirstPropertyName. In the second example, the syntax is a bit more verbose but perhaps easier to use, especially with the context-sensitive drop downs of Visual Studio: Class1b.PropertyNames.MyFirstProperty.

In the second example, note that the inner class is defined with the static keyword. That is not required, as it basically just serves as a way of making the compiler enforce that the class contains nothing but static members. That is what we want in this case. But, the downfall of a static class -- whether it is an inner class or not -- is that it cannot be derived from any class other than System.Object. That prohibits us from doing what I am going to show you next.

Imagine if the inner class in the second example was not static.



public class Class1c : INotifyPropertyChanged
{
    public class PropertyNames
    {
        public static readonly string MyFirstProperty = "MyFirstProperty";
        public static readonly string MySecondProperty = "MySecondProperty";
    }

    public event PropertyChangedEventHandler PropertyChanged;

    ...
}

Now, if we derive a new class from Class1c, we can also define a new inner class that is derived from the inner class of the base class.



public class MyClass2 : MyClass1c
{
    public new class PropertyNames : Class1c.PropertyNames
    {
        public static readonly string MyThirdProperty = "MyThirdProperty"
    }

    ...
}

That little trick with the inner class derived from the base inner class is pretty cool because the new PropertyNames class inherits the constants, fields, properties and methods of the base inner class. Therefore, we can not only access the new constants by MyClass2.PropertyNames.MyThirdProperty, but also continue to access the old constants with MyClass1c.PropertyNames.MyFirstProperty or MyClass2.ProprtyNames.MyFirstproperty.

Volatile Memory

noreply@blogger.com (TimL) — Tue, 24 Mar 2009 03:29:00 +0000

With modern computers, volatile and non-volatile memory access becomes a somewhat tricky issue. A computer may have a number of processors or cores that cache and optimize memory reads and writes directly in the hardware itself. Likewise, the compiler and runtime may also do some amount of caching and optimization. As a result of all of this caching and optimization, it is quite possible that writes to physical memory actually occur in order that is different from the order in which those writes appear in source code. As you might imagine, this can cause problems if the programmer has not taken steps to synchronize access.

For example, imagine that the following code is running on Thread 1, where both variables are fields of a class.



// Thread 1
_result = 1;
_done = true;

Next, imagine that the following code is running on Thread 2, and that Thread 2 also has access to those same fields and is waiting for _done to go true.



// Thread 2
while (!_done)
{
   Thread.Sleep(1000);
}
int result = _result;

What would you expect result to hold after the loop? Chances are, you would expect it to have a value of 1 because _result is set to 1 before _done is set to true. And, chances are you would be right some or most of the time. But, because of the caching and optimization mentioned above, it is actually possible that _done will physically be set to true before _result has physically be set to 1. Therefore, it is also possible that Thread 2 will read the old value of _result after Thread 2 sees the change in _done.

Potentially even worse, if Thread 1 continues to do some long running operation after setting _done, because of caching and optimization there is no guarantee that Thread 2 will even see the change to _done. Basically, for as long as Thread 1 continues to run, Thread 2 could be essentially deadlocked waiting for _done to change.

To get around this potential problem, .NET has the Thread.VolatileRead() and Thread.VolatileWrite() methods. The VolatileWrite() method causes the data to be written to a memory location immediatly instead of being cached. Similarly, the VolatileRead() method cause the memory location to be read directly instead of relying in a cached value.

If a field is shared between more than one concurrent thread and each of those threads always uses VolatileRead() and VolatileWrite() to access the field, the expected results will be achieved because the caching and optimziation issue will be avoided.

In addition to the Thread.VolatileRead() and Thread.VolatileWrite() methods that are part of the .NET framework, the C# language itself has a volatile keyword that can be used with fields. When volatile is used, all access to the field essentially goes through VolatileRead() and VolatileWrite() without explicitly having to use those methods.



private volatile bool _done;

And, the ECMA-334 spec (section 17.4.3) goes even further to say

A volatile read...is guaranteed to occur prior to any references to memory that occur after it in the instruction sequence.

and

A volatile write...is guaranteed to happen after any memory references prior to the write instruction in the instruction sequence.

It is important to note in those statements above that they are really talking about a reference to any field, not just the one that was marked volatile. Thus, in our trivial example, if _done was marked as volatile, then the memory for the _result field is also guaranteed to have been updated before the memory for the _done field is updated.



// Thread 1
_result = 1;
_done = true;

After all of this discussion, you will be delighted to know that you do not actually have to actually use the volatile keyword or Thread.VolatileRead() and Thread.VolatileWrite() method if you don't want to do so. Each of those techniques implements so-called "acquire semantics" and "release semantics". But, so does the standard lock that most people are familiar with. Therefore, many programmers may be more comfortable doing something like this.



private object _doneLock = new object();
private bool _done;

bool Done
{
    get
    {
        lock(_doneLock )
        {
            return _done;
        }
    }
    set
    {
        lock(_doneLock )
        {
            _done = value;
        }
    }
}



// Thread 1
_result = 1;
this.Done = true;


// Thread 2
while (!this.Done)
{
   Thread.Sleep(1000);
}
int result = _result;

Likewise, you can also use the thread-safe Interlocked class methods which also use the acquire and release semantics, but I still suspect most programmers will be happy to stick with the basic lock.

"const" vs "static readonly"

noreply@blogger.com (TimL) — Tue, 17 Mar 2009 21:27:00 +0000

A class can have some fields marked with the keyword const and others marked with the keywords static readonly. These are conceptually very similar, yet subtly different. Your choice about which to use must be based on these subtle differences.

property	`const`	`static readonly`
evaluation time	The value of a `const` field is determined at compile-time.	The value of a `static readonly` field is determined at run-time.
types	The type for a `const` field must be a `sbyte`, `byte`, `short`, `ushort`, `int`, `uint`, `long`, `ulong`, `char`, `float`, `double`, `decimal`, `bool`, `string`, an enum type, or a reference type.	The type for `static readonly` field can be anything, including a `struct` or an instance of an object allocated via the `new` operator.
reference types	Although a `const` can technically be a reference type, the only reference type it can be is a `string` or `null` since the `new` operator cannot be used to create an instance of an object at compile-time.	Because a `static readonly` field is determined at run-time, it can hold a reference to an object allocated via the `new` operator. However, since it is both `static` and `readonly`, it must be assigned in the declaration and/or static constructor.
switch statements	A `const` field can be used as a `case` in a `switch` statement because the compiler is able to determine the value to enter in the jump table.	A `static readonly` field cannot be used as a `case` in a switch statement since the value was not known at compile time.
Other Assemblies	At compile-time, the compiler obtains the value of a `const` and inserts it directly into the compiled output of the code that references the constant. This can have undesirable results! Assume, for example, that const is defined in assembly A1 and is used in assembly A2. If assembly A1 is recompiled and redistributed without also recompiling and redistributing assembly A2, then A2 will continue to use the old value of the constant that was in affect at the time assembly A2 was last compiled.	Since a `static readonly` field is assigned and obtained at run-time, other assemblies that reference that field will always use the most recent value of that field instead of obtaining the value at the time the assembly was compiled.

Raising Events

noreply@blogger.com (TimL) — Tue, 03 Mar 2009 03:01:00 +0000

Raising events is a pretty fundamental thing on the .NET world. There has been quite a bit of discussion in various blogs, forums and publications about the proper way to do it. In particular, there has been a great deal of discussion about whether you should or should not copy the delegate before invoking the delegate. This post contains my 2¢ on the subject.

Consider a simple class with a simple event MyEvent. To raise the event from within the class in which it is defined, code needs to simply call the event directly as shown in SomeMethod().



class MyBaseClass
{
    public event EventHandler MyEvent;

    ...

    private void SomeMethod()
    {
        ...
        MyEvent( this, new EventArgs() );
        ...
    }
}

As discussed in my previous post entitled Events vs Delegates, the event keyword is basically a security measure that prevents code outside of the class from raising the event. That means that classes derived from the class that defines the event cannot raise the event; in fact, derived class cannot even do anything more than call the += and -= operators on that event.

Rather than calling the event directly as in SomeMethod() above, the defactor-standard is to define an OnEvent method to raise the event. Addditionally, such OnEvent methods are typically made virtual so that derived class can "trap" the event by simply overriding the method without actually having to attach an event handler. Then, the override method in the derived class simply calls the virtual method in the base class to actually raise the event to other code that has attached event handlers.



class MyBaseClass
{
    public event EventHandler MyEvent;

    ....

    private void SomeMethod()
    {
        ...
        OnMyEvent( new EventArgs() );
        ...
    }

    protected virtual void OnMyEvent( EventArgs args )
    {
        MyEvent( this, args );
    }
}

class MyDerivedClass : MyBaseClass
{
    ....

    protected override void OnMyEvent( EventArgs args )
    {
        // Process the event
        ....

        // Call the base class to raise the event
        base.OnMyEvent( args );
    }
}

In addition to allowing the derived class to trap the event without attaching an event handler, there are other bennefits of using an OnEvent method to raise the event. In particular, there are some additonal things that need to be done before actually raising the event. And, if the event was called directly from SomeMethod() instead of going through an OnEventmethod, then that logic would have to be repeated everywhere the event is raised.

For starters, there is no guarantee that there are actually any event handlers attached to the event. And, if the event is called without any attached handlers, an exception will occur. Therefore, we need to make sure the event is not null before caling it.



protected virtual void OnMyEvent( EventArgs args )
{
    // Exit if there are no attached handlers
    if (this.MyEvent == null)
    {
        return;
    }

    // Raise the event
    MyEvent( this, args );
}

But, there is a hidden "cotcha" in the code above. That is, if the program is threaded (as most real programs are), then it is quite possible that the MyEvent event may have had one or more attached handlers when the condition was checked, but may no longer have any attached handlers by the time MyEvent( args ) is executed.

Because of this, many people recommend copying the event into another delegate, and then checking and calling the copy in that delegate. This works because delegates are value type variables. Therefore, even if handlers have been removed from the event itself by the time the delegae is called, the delegate will still get called without excetion.



protected virtual void OnMyEvent( EventArgs args )
{
    // Make a copy of all of the handlers attached to the event
    EventHandler myEvent = this.MyEvent;

    // Exit if there are no attached handlers in the copy
    if (myEvent == null)
    {
        return;
    }

    // Raise the event
    myEvent( this, args );
}

At first, I was against doing the copy but I have since reformed my ways. I have always understood why people recommended doing the copy and how it worked. But, the reason I was against the copy was because I thought it was just as dangerous to call an event handler that had already been removed. For example, when using the copy, a class may have unregistered the event handler after the copy occurred but before the delegate was called, and that event handler could end up causing some kind of exception because the class no longer expected the handler to be called (variables used in the handler may have been reset to null, etc.).

But, I realized that my logic was flawed. This is because there is no way to protect against it (short of overriding the event add and remove to use synchronization). Once the delegate is called, it essentially makes it's own copy and works on that copy, anyway. Therefore, even if an event handler was removed, it can always still be called as long as execution of the delegate started before the handler was removed.

Exception handling around a delegate is also a much debated topic. Most people recommend wrapping the call to the delegate with a try...catch, and doing Debug.Assert, logging, etc. if any exceptions were thrown by the handler methods. I also recommend this.



protected virtual void OnMyEvent( EventArgs args )
{
    // Make a copy of all of the handlers attached to the event
    EventHandler myEvent = this.MyEvent;

    // Exit if there are no attached handlers in the copy
    if (myEvent == null)
    {
        return;
    }

    // Raise the event
    try
    {
        myEvent( this, args );
    }
    catch(Exception ex)
    {
        Debug.Fail(ex.Message);
        throw; // Some people do the throw, others do not
    }

}

Although most people recommend doing the try...catch, there is debate about whether the exception should be rethrown or not. The basic argument is this: If you do not throw the exception, then code raising the event has no idea that something bad happened. But, since code raising the event has no idea about what handler methods may be attached to the event, it is not likely that any exceptions thrown by those event handler methods could be of use to the code that raised the event.

My recommend solution is kind of a hybrid of both. Basically, I prefer to create new exception class to be thrown if an exception occurs while caling a handler method, and setting the handler method's exception as the inner exception. (I'll leave the somewhat trivial implementation of EventHandlerException to your imagination.



protected virtual void OnMyEvent( EventArgs args )
{
    // Make a copy of all of the handlers attached to the event
    EventHandler myEvent = this.MyEvent;

    // Exit if there are no attached handlers in the copy
    if (myEvent == null)
    {
        return;
    }

    // Raise the event
    try
    {
        myEvent( this, args );
    }
    catch(Exception ex)
    {
        Debug.Fail(ex.Message);
        throw new EventHandlerException("MyEvent", ex);
    }
}

To me, this makes the most sense because code calling OnMyEvent() can now reasonably expect to catch an EventHandlerException if it wants to, and can even look at the inner exception if it does have reason to suspect certain types of exceptions.

Of course, no matter what you do, the act of raising the exception itself can be abstracted into a separate class so that it behaves consistently for all events.



class MyClass
{
    public event EventHandler<EventArgs> MyEvent;

    protected virtual void OnMyEvent(EventArgs args)
    {
        EventHelper<EventArgs>.RaiseEvent(
            EventHadlerExceptionType.ThrowEventHandlerException,
            this,
            this.MyEvent,
            args);
    }
}

public enum EventHadlerExceptionType
{
    EatException,
    ThrowEventHandlerException,
    ThrowOriginalException
}

public static class EventHelper<TEventArgs> where TEventArgs : EventArgs
{
    public static void RaiseEvent(
        EventHadlerExceptionType exHandling,
        object sender,
        EventHandler<TEventArgs> theEvent,
        TEventArgs args)
    {
        // No need to copy handlers because delegates are
        // value types.  The delegate has, therefore, already
        // been copied when it was passed in as a parameter.

        // Exit if there are no attached handlers in the copy
        if (theEvent == null)
        {
            return;
        }

        // Raise the event
        try
        {
            theEvent(sender, args);
        }
        catch (Exception ex)
        {
            Debug.Fail(ex.Message);
            switch (exHandling)
            {
                case EventHadlerExceptionType.EatException:
                    break;

                case EventHadlerExceptionType.ThrowEventHandlerException:
                    throw new EventHandlerException(ex);

                case EventHadlerExceptionType.ThrowOriginalException:
                default:
                    throw;
            }
        }
    }
}

For Loops, Variable Scope and Anonymous Delegates with Outer Variables

noreply@blogger.com (TimL) — Thu, 12 Feb 2009 01:06:00 +0000

There is no reason why any programming language must support built in looping. After all, even if for, foreach, while or do loops do not exist within the language itself, you could always make any of the above with a few variables, conditions and a goto statement. But, looping is such any essentially part of computer programming that most languages provide numerous loop constructs. C#.NET is no exception.

The for loop is undoubtably the most used and beloved loop construct. But, have you ever stopped to think about the details?

Consider the following code that loops ten times (from x = 0 to x = 9).


for (int x = 0; x < 10; x++)
{
    DoSomeStuff();
}

Given that most basic example above...

Do you know the real scope of variable x?

Do you know whether the condition is checked at the beginning or end of the loop?

Do you know when variable x is incremented?

As it turns out, the for loop is almost a short hand representation for slightly more verbose code using the dreaded goto statement. But, using the goto leaves little doubt about the scope of the variable, when the condition is checked, and when the variable is incremented.



int x = 0;
TopOfLoop:
if (x < 10)
{
   DoSomeStuff();
   x++;
   goto TopOfLoop;
}

But, in that code above, the variable x continues to exist after the loop has completed (which is the way some programming languages do work). In C#, however, a for is really more like this, where I have added an extra set of curly braces to ensure that x goes out of scope when the loop is over.


// Variable x does not exist
{
    int x = 0;  // Now variable x does exist
    TopOfLoop:
    if (x < 10)
    {
       DoSomeStuff();
       x++;
       goto TopOfLoop;
}
// Variable x no longer exists

In C#, variables declared in an outer scope are automatically available within the inner scopes. For example, if you declare a field on a class then it is accessible from within the class methods. If you declare a variable in a method then it is available inside other scopes within the method, such as within conditions and loops.

So, why is it important to know that? For starters, it means that you can declare the loop variable outside of the loop and it will still be available in "loop scope". And, if you declare it outside of the loop, then you can still access it after the loop has completed. Plus, it seems to be a bit more efficient to declare a variable outside of the loop body if it will be assigned a new value on every pass through the loop.


int value1;
for(int q = 0; q < 10; q++)
{
    value1 = GetValue(q);
    int value2 = GetValue(q);
}

In the example above, using value1 is more efficient than value2 because value2 goes in and out of scope on each pass, whereas value1 remains in scope the entire time.


// Variable x does not exist
for (int x = 0; x < 10; x++) // Now variable x does exist
{
    // Variable x still exists
    DoSomeStuff();
}
// Variable x no longer exists


int y;                   // Now variable y does exist
for (y = 0; y < 10; y++) // Variable y still exists
{
    // Variable y still exists
    DoSomeStuff();
}
// Variable y still exists


// Pretty much the same for variable z as for y,
// but we initialized the loop variable z outside of
// the loop instead of just declaring it outside
// of the loop.
int z = 0;               // Now variable z exists
for ( ; z < 10; z++ )    // Variable z still exists
{
    // Variable z still exists
    DoSomeStuff();
}
// Variable z still exists

In addition to the slight performance difference, there can actually be a big difference between declaring something outside of the loop vs. inside the body of the loop. For example, in the following code, are variables a, b and c always equal when DoSomething() is called?


int a = 0;
for(int b = 0; b < 10;  b++)
{
    int c = a = b;

    // Are a, b and c equal inside of DoSomething()?
    DoSomething(a, b, c);
}

Well, ok, that is kind of a trick question. In that example, they are equal. But what about in the following example using BeginInvoke, MethodInvoker and an anonymous delegate?


int a = 0;
for(int b = 0; b < 10;  b++)
{
    int c = a = b;

    // Are a, b and c equal inside of DoSomething()?
    // NOTE: this.BeginInvoke assumes we are in a WinForm
    this.BeginInvoke(new MethodInvoker(
        delegate() { DoSomething(a, b, c); }));
}

Now it becomes a much tricker question. The answer is no, they are not necessarily equal inside of DoSomething()! Don't believe me? Create the following method and give it a try.



private void DoSomething(int aa, int bb, int cc)
{
    if ( (aa != bb) || (aa != cc) || (bb != cc) )
    {
        Console.WriteLine(string.Format("{0}, {1}, {2}", aa, bb, cc));
    }
}

If you ran the loop on the main UI thread, you may suprised to see the following written to the console/output window:


9, 10, 0
9, 10, 1
9, 10, 2
9, 10, 3
9, 10, 4
9, 10, 5
9, 10, 6
9, 10, 7
9, 10, 8
9, 10, 9

What the heck? Why is a always 9 and b always 10? The call to this.BeginInvoke() "schedules" a call to DoSomething(a,b,c) to be run on the main UI thread via the MethodInvoker and anonymous delegate. Variables a and b are declared outside of the loop's body, whereas variable c is declared within the loop's body. Therefore, a and b never go out of scope during the entire loop. But, variable c goes in and out of scope on each pass through the loop.

When DoSomething() finally runs inside an anonymouse delegate on the main UI thread, it gets the current value of the outer variables a, b and c. If the variable has gone out of scope, then the current value is whatever it's value was when the variable went out of scope. Since c goes in and out of scope on each pass through the loop, the value you would expect to be passed into DoSomething() for c is passed in (i.e. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9). But, since a and b do not go out of scope on each pass, their current values at the time DoSomething() is actually called are the not the values on that pass through the loop.

If the loop was run on the main UI thread, then none of the calls to DoSomething() will occur until the loop has completed. And, in that case, a will always be 9 (because it was set to 9 on the last pass through the loop) and b will always be 10 because it was incremented to 10 before breaking out of the loop.

But, if the loop is run on the background thread instead of the main UI thread, then the values of a and b becomes a bit more unpredictable. This is because you never know when a context switch to the main UI thread to call DoSomething() will actually occur. It could occur while still running the loop, or after the loop has completed. And, if the context switch occurs around the time of the assigment c = a = b then it is possible that b as not yet been assigned to a or c; perhaps b has even been assigned to a but not c. This may not be so evident with a loop of only 10, but should become more evident if the loop is increased to, say, 100.

For example, if I run the following code, I will get something slightly different each time. Note that I use the "delegate BeginInvoke trick" to invoke DoLoop onto a background thread, and have added a Sleep(0) about half-way through the loop to make sure a context switch happens at least once so that DoSomething() has a likely chance to run at least one time on the main UI thread before the loop finishes on the background thread.



private void button1_Click(object sender, EventArgs e)
{
    MethodInvoker del = new MethodInvoker(DoLoop);
    del.BeginInvoke(DoLoop_Callback, del);
}

private void DoLoop()
{
    int a = 0;
    for(int b = 0; b < 100;  b++)
    {
        int c = a = b;
        this.BeginInvoke(new MethodInvoker(
            delegate(){
                DoSomething(a, b, c);
            }));

        
        if( (c % 50) == 0)
        {
            Thread.Sleep(0);
        }
    }
}

private void DoLoop_Callback(IAsyncResult ar)
{
    MethodInvoker del = ar.AsyncState as MethodInvoker;
    del.EndInvoke(ar);
}

private void DoSomething(int aa, int bb, int cc)
{
    if ((aa != bb) || (aa != cc) || (bb != cc))
    {
        Console.WriteLine(string.Format("{0}, {1}, {2}", aa, bb, cc));
    }
}

With that code above, I had the following output to the console.



46, 46, 0
99, 100, 1
99, 100, 2
...
99, 100, 98
99, 100, 99

If you run the code multiple times, you may get slightly different results each time.

Comparing Default Values In Generic Classes

noreply@blogger.com (TimL) — Thu, 18 Dec 2008 16:53:00 +0000

Ever since they were introduced in C# 2.0, most programmers have loved generics. I know I do! But, it can be a bit tricky to determine if a variable has been assigned or is still the default value if you do not know how to do it.

Consider the following class, and note that it

Is a generic class
Has a field name _field
Initialize _field to the default value in the constructor
Has a property IsDefaultValue that should return true if _field is still the default value (or has been assigned back the default value).


public class MyClass
{
    private T _field;

    public MyClass()
    {
        _field = default(T);
    }

    public T Field
    {
        get
        {
            return _field;
        }
        set
        {
            _field = value;
        }
    }

    public bool IsDefaultValue
    {
        get
        {
            // The following line does not compile!
            return ( _field == default(T) );
        }    
    }
}

The code default(T) causes the compiler to use the default that is appropriate for the type (null for refrence types, 0 for an int, 0.0 for a double, etc.). This is used in the constructor to assign the default value to _field. Therefore, it seems logical that we can do a comparison such as ( _field == default(T) ). But, the compiler does not like it and will complain with a message like Operator '==' cannot be applied to operands of type 'T' and 'T'.

So, the question becomes just how do you do such a comparison if you cannot do that? If you know T is a reference type, you can compare against null.


// Works only if T is a reference time
return ( _field == null );

But, that will only work for reference types and we have not put any such constraints on T.

Actually, as a side note, that code will compile for both reference types and value types but will always return false for value types. This is because, believe it or not, starting with C# 2.0, you can compare any value type to null using the == operator, but the comparison will always return false. This is a side effect of adding support for nullable types via ?.



int x = 1;
if (x == null)... // Always returns false

int? y = null;
if (y == null)... // Returns true since y is null

y = 1;
if (y == null)... // Return false since y is not null

if (x == y) ...   // Return true since x and y have the same value of 1

So, if you cannot compare against default(T) or null, what can you do to see if _field is currently set to the default value? The best way I have found to do this is shown below.



    public bool IsDefaultValue
    {
        get
        {
            return object.Equals(_field, default(T) );
        }
    }

With that change to the IsDefaultValue method, it compiles and works as you would expect.



MyClass<int> obj1 = new MyClass<int>();
bool flag1a = obj1.IsDefaultValue; // true
obj1.Field = 1;
bool flag1b = obj1.IsDefaultValue; // false

MyClass<object> obj2 = new MyClass<object>();
bool flag2a = obj2.IsDefaultValue; // true
obj2.Field = new object();
bool flag2b = obj1.IsDefaultValue; // false

WPF and TextDecoration

noreply@blogger.com (TimL) — Sat, 06 Dec 2008 04:16:00 +0000

In WPF, many classes have a TextDecorations property of type TextDecorationCollection. That property is used to add any combination of overline, strike through, underline, baseline or custom decorations to text. (For the rest of this post, I will be ignoring custom and sticking with the standard four).

When using XAML, things just kind of automagically work. The following example reads very nice, and leaves not doubt that the text will be both underlined and overlined.


<TextBlock TextDecorations="Underline, Overline">
  The quick red fox
</TextBlock>

But, when using text decorations from code, things are a bit on the weird side.

For starters, consider the following properties of the TextDecorations static class: TextDecorations.Baseline, TextDecorations.Overline, TextDecorations.Strikethrough and TextDecorations.Underline.

Sounds like a list of predefined text decorations, so what's weird with that? I find it very weird that each of those properties is actually of type TextDecprationCollection which implies it could have multiple items within the collection.

Presumably, Microsoft chose to make those properties collections so that you could directly set them in code to a TextDecorations property.


TextBlock textBlock = new TextBlock();
textBlock.TextDecorations = TextDecorations.Underlined;

And, they overload the TextDecorationCollection.Add() method so that it can take an IEnumerable(TextDecoration) (i.e. another TextDecorationCollection, etc.).

Now for the part I find very weird. Let's say I created a TextDecorationCollection instance and added to it TextDecorations.Underline, and then set a TextDecoration property to that collection. Then, if I add or remove TextDecorations to or from the TextDecorationCollection collection after it has already been set to the property, those changes are not rendered. One way around this is to set the property to null, add the decorations to the collection, and then set it back.


TextDecorationCollection tdc = 
    textBlock.TextDecorations;

textBlock.TextDecorations = null;

tds.Add(TextDecorations.Strikethrough);

textBlock.TextDecorations = tds;

Or, I could also create a new instance using the overload that acts like a copy constructor.



TextDecorationCollection tdc =
   new TextDecorationCollection(textBlock.TextDecorations);

tds.Add(TextDecorations.Strikethrough);

textBlock.TextDecorations = tds;

?, ?? and Casting

noreply@blogger.com (TimL) — Sat, 06 Dec 2008 03:40:00 +0000

I have previous written a post on the use of the ? and ?? operators and nullable types. If you recall, you can make any value type by declaring it with the ? operator:


int? myIntA;

Also, you may recall that when you use the value of a nullable type, you must also supply a value to use if the value of the nullable type is null. If you think about it, this makes perfect sense. If myIntA was null in the example above, what the heck does it mean to 100 to myIntA? The compiler has no idea, so you must tell it, which is really one of the main reasons why the ?? operator was added.


int myIntB = 100 + (myIntA ?? 0);

But what if you already know the value is not null? Do you still have to supply a "dummy" value to use for null even though you know it will never be used? The answer is no, because you could always cast it to a non-nullable type:


if (myIntA == null)
{
    myIntB = 100;
}
else
{
    myIntB = 100 + (int)myIntA;
}

The casting approach is not so handy in the example above because it's just a more verbose way of doing the same calculation, but it does illustrate the point. And, there are many times, where the casting is the way to go. For example, what if you wanted to call a different method based on whether the value was null or not?



if (myIntA == null)
{
    Method1();
}
else
{
    Method2( (int)myIntA );
}

==, .Equals() and ReferenceEquals()

noreply@blogger.com (TimL) — Thu, 26 Jun 2008 23:24:00 +0000

C#.NET offers a variety of ways of testing for equality. For the most part, things just work as the programmer would expect. But, because the == operator and Equals() method can be overriden, some guidelines have been established by Microsoft to ensure that things continue to work as expected.

For starters, just what does the == operator do? Well, that depends on what type of data you are dealing. For the predefined value types, the == operator returns true of the values are equal. For predefined reference types (except strings), the == operator returns true if both sides reference the same object. And, the System.String class (a predefined, immutable reference type) overrides the == operator to return true if both sides have the same value.

For your own classes, you can override the == operator to do a value comparison instead of a reference comparison, but that does not mean you should! You should seriously think twice before doing that because most programmers will assume it is still a reference comparison.

If the System.String overrides == to compare string values, just what does it mean for two strings to have the same value? The string's == operator actually calls the static String.Equals(string, string) method. And, that method will return true if...

Both parameters are null

Both parameters reference the same object

Both parameters are have the same number of characters (i.e. same length) and the ordinal value of each character is the same

Note that String.Equals() compares the ordinal value. This means that the comparison is inherently case-sensitive and culture-insensitive. That is, the Unicode values of the characters at each position in the two strings must be same.

Ok, so you can use the == operator to compare the value of two strings. But, what if you want actually do want to compare two string variables to see if they reference the same thing? One common "trick" people do is to cast one (or both) of the string variables to an object. Because one side is now an object, the compiler will use System.Object's == operator instead of the System.String operator to do that comparison, and that operator will do a reference comparison.


bool flag = (object)a == b;

That works, but should you do that? I say "no". Why? The reason is simple: because Visual Studio will underline that code with a green squiggly line, and when you mouse over it the tooltip says "Possible unintended reference comparison; to get a value comparison, cast the left hand side to type 'string'". Basically, they are telling you that something is "fishy" and that means it does not fall under best practices.

By now. You may be asking yourself If the cast-trick above is not best practices, how do I compare two strings to see if they reference the same value? OR, If the == operator may have been overridden to compare values, how do I know I am actually comparing references? Truth-be-told, the answer to both of those questions is the same: use the static System.Object.ReferenceEquals() method instead.

The Object.ReferenceEquals() method unequivocally compares two references to see if they reference to the same instance an object. With normal objects, this is pretty straight-forward to understand. But, once again, things actually get a bit tricky with strings as is shown in the example below.


string a = "12";
string b = "1" + "2";
string c = "1"; c += "2";

// flagA1, flagA2, flagA3 and flagA4 are all true
// because they were all assigned by value comparisons.
bool flagA1 = (a == "12");
bool flagA2 = (a == a);
bool flagA3 = (a == b);
bool flagA4 = (a == c);

// flagB1, flagB2 and flagB3 are all true because the
// compiler interns the variables a & b and literal "12"
// to the same string.
bool flagB1 = object.ReferenceEquals(a, "12");
bool flagB2 = object.ReferenceEquals(a, a);
bool flagB3 = object.ReferenceEquals(a, b);

// flagB4 is false because variable c was created by
// concatenating two values at run-time, and therefore
// is not interned to the same "12" as variables a & b
// literal "12".  Sure, variable b was concatenated too,
// but that was at compile time so it was still interned.
bool flagB4 = object.ReferenceEquals(a, c);

There are a few more things to be aware about when it comes to comparisons using the == operator. Ever here of boxing and unboxing? The == operator will compare the values of two value-type parameters, but boxed parameters are no longer value type parameters!


bool CompareBoxedValues(object a, object b)
{
    return (a == b);
}

int a = 1;
int b = 1;

// flag1 is true because the two values are equal
bool flag1 = (a == b); 

// flag2 is false because the two variables are boxed
// into different objects
bool flag2 = CompareBoxedValues(a, b);

// flag3 is also false because the same variable is
// boxed into two different objects
bool flag3 = CompareBoxedValues(a, a);

So now think back to that Object.ReferenceEquals() method. What do you think happens if you pass non-references (i.e. values) into it? Sure enough, each value gets boxed into a different object instance so the method always returns false!


// The following always sets flag to false
int a = 1;
bool flag = ReferenceEquals(a, a);

That pretty much covers a few of the basics of comparisons in .NET. But, once again, string comparisons prevent a host of problems. Do you want to do a case-sensitive or insensitive comparison? What about cultural based comparisons? To see if you will get burnt by a Turkey, see the blog post from my colleague Jeff Moser in the office next to me.

Statics and Generics

noreply@blogger.com (TimL) — Mon, 23 Jun 2008 17:08:00 +0000

If you think about it, it makes total sense. But, this is something you need to be careful of if you are use static member variables inside of generic classes. Basically, each different type you pass into a generic creates a new class, and each of those classes has its own set of static member variables!

As an example, consider the following trivial example class.


class MyGenericClass<T>
{
    private static int s_IdCounter = 0;

    private int _id;

    private T _value;

    public MyGenericClass(T value)
    {
        _id = Interlocked.Increment(ref s_IdCounter);
        _value = T;
    }

    public int Id
    {
        get
        {
            return _id;
        }
    }

    public T Value
    {
        get
        {
            return _value;
        }
    }
}

Now, consider what happens to the Id property when you create the following instances.


MyGenericClass<object> obj1 = new MyGenericClass<object>(null);
MyGenericClass<object> obj2 = new MyGenericClass<object>(null);
MyGenericClass<string> obj3 = new MyGenericClass<string>(null);

The actual values of the Id properties for those objects are.


obj1.Id == 1
obj2.Id == 2
obj3.Id == 1

The reason this occurs is because obj1 and obj2 are of the same type (MyGenericClass<object>) whereas obj3 is actually of a different type (MyGenericClass<string>). If you truely need them to share the same set of static member variables, then you need another class that contains the statics. You can either derive your generic from that other class, or you can have the generic use that other class. I personally prefer the later because I feel that a class intended to only hold static member variables should be a static class, but the compiler will not let you derive a non-static class from a static class.

Mouse Pointers and Cursors

noreply@blogger.com (TimL) — Thu, 19 Jun 2008 22:06:00 +0000

We've all seen it, and we all want to do it. If an application is busy doing something for extended period of time, we want to change the cursor so that the user knows the application is still busy. But, cursor control can be a bit confusing in C#.NET because there are several ways to control the cursor. I'll try to sum how cursors behave for WinForms within this post.

For starters, just to get the terminology straight from a Windows' point of view, the mouse pointer is the location on the screen that changes as the user moves the mouse, and the cursor is the graphical image that is drawn with its hot spot at the mouse pointer.

In .NET, each cursor image is represented by an instance of the System.Windows.Forms.Cursor class. Instances of the Cursor class can be used to represent the standard Windows cursors, as well as custom-defined cursors (generally compiled into a resource file).

Instances of Cursor that represent the standard Windows cursors are available as static properties of the System.Windows.Forms.Cursors class. For example, Cursors.WaitCursor returns an instance of a Cursor that contains information about how to display the "wait cursor" configured in Windows.

In addition to using instances of the Cursor class to define what different cursors look like, the Cursor class also has several static properties that described the currently active cursor. Most noteably, the Cursor.Current property sets or gets the Cursor instance that is currently active, and Cursor.Position property gets or sets the current location of the mouse pointer.

These static properties describing the current cursor are a bit interesting when it comes to threaded applications. No matter what thread you are on, the Cursor.Position property always gets or sets the Windows mouse pointer position immediately. But, the Cursor.Current property does not behave the same way!

Although you can do it without throwing an exception, getting or setting the Cursor.Current property form any thread other than the main UI thread is somewhat pointless. If you get the Cursor.Current property from a non-UI thread, you will notice that it defaults to Cursors.WaitCursor even if the actual Windows cursor is something else. And, if you set the Cursor.Current property from a non-UI thread the actual Windows cursor will not change. After doing so, however, calling get from a non-UI thread will return that set value.

Each WinForms control has a Cursor property inherited from the System.Windows.Forms.Control class. When the mouse pointer is over a control, the Windows cursor is changed to whatever is specified by the Cursor property of the control, and the Cursor.Current property is changed to return that cursor as well.

The Control.Cursor property is a so-called ambient property. That means a control will use its container's cursor as long as it has not been specifically set on the control itself. For example, if you have a button on a form, then setting the Cursor property of the form (both in Visual Studio and prgrammatically at run-time) will also change the cursor for the button as long as you have not specifically set the button's Cursor property.

Setting the Cursor.Current property from a non-UI thread may not be useful, but setting it from the main UI thread is a way of temporarily overridding the cursors specified by the Cursor properties of all controls in the application (or at least those on the same UI thread). Setting the Cursor.Current property from the main UI thread changes the Windows cursor immediately and application-globally, but only temporarily. Once Cursor.Current is specifically set, it will continue to override the controls' cursors until it is changed to something else, or until the UI thread "catches up" and runs out of messages to process.

If you know you are going to execute code that will block the main UI thread for a bit, you could set Cursor.Current before executing that code and not have to worry about setting it back or changing it on every form. Once the UI starts responding again, the cursor will go back to being whatever is set on the Control.Cursor property of the control the mouse pointer is over.

If you know you are going to block the main UI thread fo awhile, you could set the Cursor.Current to Cursors.WaitCursor, and Windows would display the wait cursor for the entire application until the main UI thread was no longer busy. But, ideally we do not want to block the main thread for extended periods of time because non-responsive, partially-painted applications not only look bad but also make users think something is wrong. So, unless a long-runnning task has to be on the main UI thread (such as when creating a bunch of items for a combo box), most programmers should choose to do long-running tasks on background threads or in dedicated threads so the main UI thread is not blocked. But, in such cases, we cannot use Cursor.Current to display the wait cursor because the cursor would immediately reset to whatever is appropriate for the control the mouse pointer is over because the UI would be responsive. That's where the UseWaitCursor properties come in!

Each WinForms control has a UseWaitCursor property inherited from System.Windows.Forms.Control. When this property is true, the wait cursor is used instead of whatever cursor is specified in the Control.Cursor property whenever the mouse pointer is over the control or any of it's child controls.

The System.Windows.Forms.Application class also has a UseWaitCursor property. Setting Application.UseWaitCursor causes the framework to loop over all of the open forms and set the Control.UseWaitCursor properties on all of those forms.

There are a few last subtle point to note...

Unlike the Cursor.Current property that assumes the main UI thread will be blocked and therefore changes the Windows cursor immediately, setting the Control.UseWaitCursor or Application.UseWaitCursor properties assumes the UI will remain responsive and therefore does not change the Windows cursor immediately but instead processes it as any other property change. Therefore, if you set the UseWaitCursor and then block the UI thread, you may never see it!

Also, if UseWaitCursor is true, then setting the Cursor.Current cannot be used to override the wait cursor.

And, using the wait cursor via UseWaitCursor does not prohibit other mouse events. It is still possible for the user to press buttons, size forms, enter text, etc. even if UseWaitCursor is true.

Finally, there are even more ways to change the cursor, such as via the DragDropEffects! (Perhaps I will blog about how they interact with the cursors mentioned above in the future?)

Cannot Multi-Select in File Explorer on Vista

noreply@blogger.com (TimL) — Tue, 20 May 2008 17:36:00 +0000

I was one of the "early adopters" of Vista. Soon after I installed it, my File Explorer windows started doing two strange things.

Putting a little checkbox next to highlighted files or folders

Multi-select did not work with Ctrl+A, Ctrl+Click or Shift+Click

The chekbox thing was not that big of a deal; it was more of a visual annoyance. I found out later that the checkboxes could be turned on or off via configuration.

Open File Explorer

Pull down the Tools menu

Select Folder Options...

Select the View tab

Uncheck the Use check boxes to select items option

The inability to multi-select, however, is a huge burden on the usefullness of the operating system itself. I had tried several suggestions from various blog postings and message boards, but none of them seemed to work. Finally, I stumbled across a post that had a "fix" that worked on my machine. If you have problem with multi-select in Windows Vista, delete the following two registry keys and then reboot your computer.:

HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU

HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags

Calling an instance method from outside the class before the constructor completes

noreply@blogger.com (TimL) — Fri, 11 Apr 2008 15:51:00 +0000

If I asked the question "Can you call an instance method on an object before the constructor completes?", most programmers would think about it for awhile and then likely conclude "Sure, I do it all the time. It is very common to have the constructor itself call an instance method."


class MyClass
{
    MyClass()
    {
        MyMethod();
    }

    void MyMethod()
    {
    }
}

But, what if I change the question a bit: "Can you call an instance method on an object from outside the class before the constructor completes?". What would your answer be then? I am guessing that most programmers may assume that cannot happen. If you assume that cannot happen, then "you assume to much" (stealing a line from Padme).

I suspect many readers of this posting are now thinking "Huh?", "What?" and "How could you do that?". How do you call a method from outside the class before the constructor has completed? In the typical usage, the constructor would always complete before calling a method from outside the class:


SomeClass someClass = new SomeClass();
someClass.SomeMethod();

But, things are not always typical, especially as programs move more asynchronous in nature. Although it is probably not desirable for code outside of a class to call an instance method on an object before its constructor has completed, there is a very really danger that this can happen! Consider, for example, the following two classes.



public class Class1
{
    private object _someObject;

    public Class1()
    {
        Class2 class2 = Class2.Instance;
        class2.SomeEvent += new EventHandler(Class2_SomeEvent);
        class2.Go();

        System.Threading.Thread.Sleep(5000);
        _someObject = new object();
    }

    private void Class2_SomeEvent(
        object sender,
        EventArgs e)
    {
            Type type = _someObject.GetType();
    }
}

public class Class2
{
    private static Class2 _instance = new Class2();

    public event EventHandler SomeEvent;

    private Class2()
    {
    }

    public static Class2 Instance
    {
        get
        {
            return _instance;
        }
    }

    public void Go()
    {
        MethodInvoker del = new MethodInvoker(DoSomething);
        del.BeginInvoke(new AsyncCallback(DoSomething_Completed), null);
    }

    private void DoSomething()
    {
    }

    private void DoSomething_Completed(IAsyncResult ar)
    {
        OnSomeEvent();
    }

    private void OnSomeEvent()
    {
        if (SomeEvent == null)
        {
            return;
        }

        try
        {
            SomeEvent(this, new EventArgs() );
        }
        catch(NullReferenceException ex)
        {
            Debug.Assert(false, "The Class1 constructor has not completed yet!");
        }
    }
}

In this example, Class2 is a very simple singleton that provides a Go() method, and a SomeEvent event. The constructor for Class1 registers for the event. And, for simplicity of this example, the Class1 constructor is also calling the Go() method, but it could potentially be called by other code outside of both Class1 and Class2. Also, note that I have intentionally added a Sleep() to the example to ensure that you see the problem.

So, there you have it. If you run the code above, you will get an assert because _someObject is null when the Class1.Class2_SomeEvent() event handler is called even though _someObject is explicitly set in the Class1 constructor.

If, from within a class constructor, you register for event handlers or pass delegates into asynchronous methods as callbacks, there exists a possibility that your event handler or callback may get invoked before the constructor has completed.

More on Control.BeginInvoke()

noreply@blogger.com (TimL) — Fri, 21 Mar 2008 21:02:00 +0000

By now, everyone knows you use Control.BeginInvoke() to asynchronously execute a delegate on a the main UI thread, right? But, what happens if you call Control.BeginInvoke() while already on the UI thread?

The answer is simple: it does the same thing -- it asynchronously invokes the delegate on the main UI thread.

Huh? What does that mean if you are already on the UI thread?

If you are already on the UI thread, you can use Control.BeginInvoke() to queue a delegate to be executed on the main UI thread. It is added to the end of everything else that is already queue to be processed on the UI thread. For example, consider the example below.


private void Button_Click(
   object sender,
   EventArgs e)
{
   _label.Text = "1";
   BeginInvoke( new MethodInvoker( delegate() { _label.Text = "2"; } ));
   _label.Text = "3";
}

What would you expect _label.Text to be? After setting it to "1" its value is "1". After the BeginInvoke() its value is still "1". After setting it to "3" it's value is "3". Sometime after Button_Click has returned, the anonymous method will run and _label.Text will change to "2".

So are there really any reasons why you would want to use this? Sure, but I don't have time to get into that now. Perhaps I will post about them in the future.

TimL on C#.NET has moved!

noreply@blogger.com (TimL) — Thu, 20 Mar 2008 22:01:00 +0000

I have successfully moved http://csharp.timl.net to http://timl.net.

TimL on C#.NET is moving!

noreply@blogger.com (TimL) — Wed, 19 Mar 2008 21:10:00 +0000

Sometime over the next few days, I will be moving my C# blog from http://csharp.timl.net to simply http://timl.net. I don't know for sure if it will affect anybody that subscribes to the feed, but I don't think it will. Never-the-less, I just thought I'd post this message incase any readers run into problems.

Are reads and writes of reference type variables atomic?

noreply@blogger.com (TimL) — Fri, 15 Feb 2008 22:25:00 +0000

This question came up at work today:

If you have a class that has a getter and setter for a property that is a reference type (such as a user defined class) and that property will be accessed by multiple threads, do you have to protect access to getting or setting the underlying member variable?

Bascially, the other developer was asking if he had to do the following:



class MyClass1
{
}

class MyClass2
{
    object _syncLock = new object();

    MyClass1 _myClass1;

    MyClass1 Value
    {
        get
        {
            lock(_syncLock)
            {
                return _myClass1;
            }
        }
        set
        {
            lock(_syncLock)
            {
                _myClass1 = value;
            }
        }
    }
}

My answer was "I never do". But, I soon as a paniced feeling as I started to second-guess myself. Do I need to do that? Had I been doing it wrong in everything .NET app I have ever written?

After thinking about it for awhile, I came to conclusion that setting and getting a reference variable has to be an atomic operation.



object a = new object();
object b;
b = a;  // This line must be atomic!

If it was not, I reasoned, then the lock() statement we all love could not possibly be used to protect access to anything because the object referred to by the reference variable that is passed into lock could be changed by another thread as it was in-process of being assigned as the lock object for the Monitor.

After to coming to this conclusion, I went to ECMA-334 to see if it had a concrete statement of what I had just determined must be. Sure enough, section 12.5 Atomicity of Variable References states:

Reads and writes of the following data types shall be atomic: bool, char, byte, sbyte, short, ushort, uint, int, float, and reference types. In addition, reads and writes of enum types with an underlying type in the previous list shall also be atomic. Reads and writes of other types, including long, ulong, double, and decimal, as well as user-defined types, need not be atomic. Aside from the library functions designed for that purpose, there is no guarantee of atomic read-modify-write, such as in the case of increment or decrement.

Ok, case closed. But this also implies something else. This means that there is an upper limit of the number of objects that can exist in .NET at any one time. Assuming that each instance of an object is assigned a unique "reference" number, that number is probably 32-bit since that is the largest number of bits that can natively be copied atomically on a 32-bit system. This means that the absolute maximum number of objects that can exist in .NET at any point in time is 2^32 = 4,294,967,296. Assuming that each of those objects took only 4-bytes to store its unique 32-bit number and nothing else, that would be 2^32 * 4 = 17,179,869,184 bytes (16GB) of memory to create every possible instance of simple objects, so I don't think we're going to run out anytime soon. Although, I can recall when 640K was considered to be 10x the amount of RAM a PC would ever need.

Unable to cast object of type 'Y' to type 'Z'

noreply@blogger.com (TimL) — Sat, 09 Feb 2008 07:24:00 +0000

The other day, I had a very strange exception. I had an object that very clearly implemented an interface. Yet, when I tried to cast the object to the interface using as, the cast always returned null.



interface IMyInterface
{
   void MyMethod();
}

class MyClass : IMyInterface
{
    void MyMethod()
    {
    }
}

MyClass myClass = new MyClass();
IMyInterface myInterface = myClass as IMyInterface();

if (myInterface == null)
{
    Debug.Assert(false, "What the heck?);
}

Since my application uses interfaces extensively, this seemed like a break-down in the very fabric of the .NET space-time continuum. All of the other casts of objects to interfaces were working fine, except for this one object. If there's one thing my years of enigneering and computer programming has taught me, it's that there is always a reason why something really weird happened.

I tried everything, and even verified that the object instance did indeed support the interface by using .GetType().GetInterface() and .GetType().GetInterfaces(). Since casts using as "fail gracefully" and return null, I tried casting using (IMyInterface) instead to see if I could get an exception. Sure enough, I got an exception:

"The type initializer for 'X' threw an exception. Unable to cast object of type 'Y' to type 'Z'"

This "type initializer" exception did, of course, clue me in that there was assembly version issue. But where? I double-checked all of our make files (we build at the command line instead of in Visual Studio), deleted all DLLs to make sure there was not some kind of circular reference of the assemblies, closed Visual Studio and all other apps to make sure nothing was keeping a file locked, rebooted the computer, etc. I spent hours trying to figure out what was happening. Then, by accident, I started the release version of our software instead of the bug version, and it worked!

That was new information -- it works in release mode by not in debug mode. Our build process generates two separate sets of binaries: release and debug. And, the filenames for the debug binaries all end in the letter "D".

With this new information, I was eventually able to find the culprit. Although the application is a WinForms app, it uses XamlReader and XamlWriter to serialize and deseialize some custom WPF objects that get displayed in an ElementHost control. And, in the assembly that contained our custom controls, I had accidentally omitted the XmlnsDefinition assembly attribute that maps an XML namespace to a .NET namespace. As a result, the XamlWriter was putting the assembly name into the XAML file.

Since our debug assemblies end in "D" but the release assemblies do not, the XAML files that were generated from release software could only be loaded in release software, and files generated by debug software could only be loaded by debug software. It just so happes that, during my hours of frustration, I was using the debug version of our software but trying to load XAML files that had apparently been created from our release version.

Once I found the problem, the solution was simple: adding the XmlnsDefinition made the problem go away because the XML namespace was written into the file instead of the assembly. But, it really got me thinking. Anytime an assembly is loaded by name, this problem could exist. For example, the the Type.GetType() method allows you to load a type from a "type,assembly" string.



// Create and instance of type MyNameSpace.MyType from assembly MyAssembly
Type myType = Type.GetType("MyNameSpace.MyType,MyAssembly");
MyType myType = (MyType)Activator.CreateInstance(type);