Remember to set SynchronizingObject property for System.Timers.Timer objects in .NET WinForms

Found this out the hard way.

I'm currently building a cool animated window, and instead of using the drag-n-drop timer for WinForms I wanted to just use a timer in code (in this case System.Timers.Timer), since I need it to go into a couple of modes, and it just seemed more straightforward since all my code related to the timer could be just in my .cs file, and not spread across the .Designer.cs and the .cs files.

When I tried to set a property on the form from the event handler I had set up that responded to the Timer's Elapsed event, I was getting a nasty "Control control name accessed from a thread other than the thread it was created on" error.

After scanning the help documentation (see the MSDN Help Link), it turns out that when using a timer with a form, it's advisable to set the SynchronizingObject property to the form object to prevent the aforementioned threading error:

If you use the Timer with a user interface element, such as a form or control, assign the form or control that contains the Timer to the SynchronizingObject property, so that the event is marshaled to the user interface thread.

The good news is that after setting the SynchronizingObject to the form object, the threading issues went away and the form started to behave correctly!

Extract Superclass Refactoring on UserControl

Yesterday I ran into an interesting problem when working on an internal application:

• How do you perform an "Extract Superclass" on an existing UserControl in .NET?
  

I then posted this question on the MSDN Forums.

Honestly, I was hoping that there would be a tool for doing this, or at least a documented process. No such luck.

So, I went ahead and did my best to perform the refactoring, all the while documenting the procedure.

To summarize, here are the steps:

As promised, here's an oversimplified list of the things I did to accomplish this:

1. Created a new UserControl to use as the base (let's just call it "BaseUserControl").
2. Moved private member variables, event handlers, and other methods pertinent to the functionality I wanted up into BaseUserControl.
3. Copied control(s) I needed from OriginalUserControl into the BaseUserControl using the visual designer (it's just easier that way, plus resources are managed correctly).
4. Hooked up BaseUserControl events to the event handlers using the visual designer (again, it was just easier).
5. Commented out duplicate code in OriginalUserControl (i.e. the methods, etc. that were moved up)
6. Changed the inheritance of OriginalUserControl from UserControl to BaseUserControl.
7. Build, fix, build...

...and it worked! Now I can build a NewUserControl based on BaseUserControl and it will have all the functionality that I was wanting in the container, but I can still add more controls, etc. specific to each case I need it.

I just wanted to mention again why I wanted to do this in the first place, since it may seem weird to go through all this:

• First, I created a pretty useful control for a project I was working on, but didn't think about reuse (oops!).
• Naturally, it became apparent that I would need another similar component after the initial proof-of-concept was done.
• After determining that the functionality of the container could be used in other controls, I needed a way to pull that functionality up so that I could use inheritance to create new user controls based on the container.

Actually it wasn't as bad as I thought, though it sure would be nice if this was an automated process, or at least if there was a documented step-by-step how to on the subject.

At any rate, I sincerely hope this helps other developers faced with a similar challenge!

Eclipse Process Framework

I just got through listening to a year-old podcast (at the time of this writing) by DotNetRocks! in which they interview Scott W. Ambler.

In this podcast, he talks about an interesting tool, the Eclipse Process Framework, and it sounds like a really interesting tool for customizing software development processes:

The Eclipse Process Framework (EPF) aims at producing a customizable software process enginering framework, with exemplary process content and tools, supporting a broad variety of project types and development styles.

I'm not sure if this is something I would use, but one thing is certain:

• no one process works for all organizations.

All groups are different, and some have legacy processes that they prefer or use.

So the notion of being able to pick and choose process components to fit your situation and organization is pretty compelling.

Plus, it's all free and available as an Eclipse plug-in, which is pretty cool too.

Visual Studio Wish List: Default to Code View in Windows Forms?

This one has been bugging me for a while (since the first version of VS .NET), but why is it that the HTML Designer options in Visual Studio 2005 allow you to default to Design or Code view, but that option is not available under the Windows Forms Designer options?

I'm working in the code most of the time, and am in the visual designer just a very small percentage of the time, so why can't I set the default to just open the code window?

Crazy.

Hopefully this has been fixed in Visual Studio .NET 2008, but I'm not keeping my hopes up. Alternatively, perhaps this option will be available in the WPF form designer, which would be an improvement - and I can see myself moving in that direction.