An interesting, although generally basic, problem with Windows Forms is how to implement the singleton pattern on the forms. What do I mean? Well, consider this…

You’re writing a Windows Forms application and you have a bunch of Forms, such as a Preference window, an About window and so on. You’d like these forms to be modeless, yet you don’t want the user to be able to create more than one of them.

It’s a common problem, but there’s no built in way to handle it. Moreover, I’ve yet to see an elegant solution to it. The method explained below, which is as elegant as it’s going to get, creates a pseudo-factory class to manage the problem for you. Read on to find out more.

If a Form were just any old object, you could implement the Singleton pattern in the said class:

Of course, this isn’t thread safe - there are much better ways to do this in the general case. See here for a good explanation. In the case of forms, however, we don’t need to be thread safe. Windows forms are explicitly un-threadsafe themselves. They should (in most cases) only ever be initialized/used from a single thread. This constraint applies here too.

Now, this won’t work for Windows Forms. How come? Well, once the Windows Form has been closed (with Close() or otherwise) it, generally, gets disposed. We all know you can’t use a disposed form again. You’ll get a crash when trying to access the form again. So, what’s the work around?

Basically, we need to handle the FormClosed event, so that we know the form has been closed. We can then remove the reference to the form, once its been closed, and start all over again next time it’s needed. So we’d end up with something like this:

Now we’re getting closer. It seems unnecessary, however, to implement this on every single form that we want to be a singleton form: It’s a lot of copying identical code, and it’s prone to bugs.

So what can we do? We create a provider class which creates singleton forms for us. Sort of like a singleton factory with a few little tricks to ensure only valid forms are around. I’ve seen code before for this on various blogs / message boards, but none of them are as complete as this one.

What’s the difference? It’s the use of generics that makes this implementation really handy. By using a generic method, we can return a form of the correct type: there’s no need to worry about casting.

Another modification is the addition of a parameters to the GetInstance method. Although this is a little dodge, and could break things if you aren’t careful, I’ve found it handy when used with a form whose constructor required extra arguments.

So here it is:

and to use it:

Well, there you have it. A handy Generic Singleton Form provider for C#.