While working with the RegistryKey class today, I noticed that even though it implements IDisposable, it does not publicly expose Dispose(). Read on to find out why.

We start with a general discussion of explicit interface implementations. Suppose you have the following two interfaces:

interface Foo {
    void Hello();
}
interface Bar {
    void Hello();
}

Then, in the following class, both Foo.Hello and Bar.Hello will call this classes implementation of Hello:

class Baz : Foo, Bar {
    public void Hello() {
        /* do something here. */
    }
}

And of course, if we wanted separate implementations for Foo.Hello and Bar.Hello we would do:

class Baz : Foo, Bar {
    void Foo.Hello() {
        /* do something here. Called by Foo.Hello */
    }
    void Bar.Hello() {
        /* do something here. Called by Bar.Hello */
    }
}

Now, notice that the public access modifier is no longer present. Try putting the public access modifer in, and you’ll get an error: The modifier ‘public’ is not valid for this item. This is because if Baz exposed Hello publicly, it wouldn’t be clear which Hello was to be called. And indeed, you can’t simply call Hello() on an instance of Baz, you have to cast it to Foo or Bar first:

void SomeFunction() {
    Baz b = new Baz();
    b.Hello(); /* ERROR: will not compile */
    ((Foo)b).Hello(); /* Calls Foo.Hello */
    ((Bar)b).Hello(); /* Calls Bar.Hello */
}

OK, so this is all pretty basic and most C# developers will be aware of all this. Most people will have stumbled across it by necessity.

So now I look at the lesser known property of explicit interface implementations: used to “hide” interface implementations that aren’t in conflict.

You may be surprised to know that if you remove the inheritance from, say, Bar in the above class, the thing will still compile:

class Baz : Foo {
    void Foo.Hello() {
        /* do something here. Called by Foo.Hello */
    }
}

Moreover, when you try to do something like this:

void SomeFunction() {
    Baz b = new Baz();
    b.Hello(); /* ERROR: will not compile */
}

You’ll receive an error: “‘Baz’ does not contain a definition for ‘Hello’”. You’ll notice that we don’t provide the public access modifier to Foo.Hello in our Baz class, so of course we get such an error. So it turns out that you can essentially hide interface members of a class. From the Implementing Interface Members Explicitly documentation on MSDN:

When an interface member is explicitly implemented by a class, the member can be accessed only by using a reference to the interface. This has the effect of hiding the interface member

It turns out that this is what RegistryKey() does with IDisposable.Dispose(). Dispose() is hidden by using explicit interface implementations. So you can do the following:

void SomeFunction(RegistryKey key) {
    ((IDisposable)key).Dispose();
}

But not:

void SomeFunction(RegistryKey key) {
    key.Dispose();
}

So why would you want to do this? Well, the documentation cited before also states:

Consider implementing interface members explicitly to hide a member and add an equivalent member with a better name.
This effectively renames a member. For example, Stream implements Dispose explicitly and provides the Close method in its place.

I guess this was the intention with RegistryKey. It seems to me, however, that this reasoning is a bit silly. Dispose, according to MSDN, “performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources.” Isn’t this what we want to happen when we are done with a RegistryKey instance? I would suggest that the member with the “better name” here is Dispose, not close. If we’re working in the .NET paradigm, we should stick to Dispose. Many classes could then avoid the need to have Close() at all, and ensure that novice .NET developers are exposed to IDisposable more often. Alas, it is not the case.

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:

class SomeSingletonClass {
    protected SomeSingletonClass () {
    }

    private static SomeSingletonClass mInstance = null;

    public static SomeSingletonClass Instance {
        get {
            if (mInstance == null) mInstance = new SomeSingletonClass();
            return mInstance;
        }
    }
}

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:

class SomeSingletonForm : Form {
    protected SomeSingletonForm () {
    }

    private static SomeSingletonForm mInstance = null;

    public static SomeSingletonForm Instance {
        get {
            if (mInstance == null)
            {
                mInstance = new SomeSingletonClass();
                mInstance.FormClosed += new FormEventHandler(remover);
            }
            /* Could call mInstance.Show(); */
            return mInstance;
        }
    }

    static void remover(object sender, FormClosedEventArgs e)
    {
        mInstance.FormClosed -= new FormClosedEventHandler(remover);
        mInstance = null;
    }
}

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:

    class SingletonFormProvider
    {
        static Dictionary<Type, Form> mTypeFormLookup = new Dictionary<Type, Form>();

        static public T GetInstance<T>(Form owner)
            where T : Form
        {
            return GetInstance<T>(owner, null);
        }

        static public T GetInstance<T>(Form owner, params object[] args)
            where T : Form
        {
            if (!mTypeFormLookup.ContainsKey(typeof(T)))
            {
                Form f = (Form)Activator.CreateInstance(typeof(T), args);
                mTypeFormLookup.Add(typeof(T), f);
                f.Owner = owner;
                f.FormClosed += new FormClosedEventHandler(remover);
            }
            return (T)mTypeFormLookup[typeof(T)];
        }

        static void remover(object sender, FormClosedEventArgs e)
        {
            Form f = sender as Form;
            if (f == null) return;

            f.FormClosed -= new FormClosedEventHandler(remover);
            mTypeFormLookup.Remove(f.GetType());
        }
    }

and to use it:

AboutBox abox = SingletonFormProvider.GetInstance<AboutBox>(this);
abox.Show();

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