Question

UPDATE

I have combined various answers from here into a ‘definitive’ answer on a new question.

Original question

In my code I have an event publisher, which exists for the whole lifetime of the application (here reduced to bare essentials):

public class Publisher
{
    //ValueEventArgs<T> inherits from EventArgs
    public event EventHandler<ValueEventArgs<bool>> EnabledChanged; 
}

Because this publisher can be used all over the place, I was quite pleased with myself for creating this little helper class to avoid re-writing the handling code in all subscribers:

public static class Linker
{
    public static void Link(Publisher publisher, Control subscriber)
    {
         publisher.EnabledChanged += (s, e) => subscriber.Enabled = e.Value;
    }

    //(Non-lambda version, if you're not comfortable with lambdas)
    public static void Link(Publisher publisher, Control subscriber)
    {
         publisher.EnabledChanged +=
             delegate(object sender, ValueEventArgs<bool> e)
             {
                  subscriber.Enabled = e.Value;
             };
    }
}

It worked fine, until we started using it on smaller machines, when I started getting the occasional:

System.ComponentModel.Win32Exception
Not enough storage is available to process this command

As it turns out, there is one place in the code where subscribers controls are being dynamically created, added and removed from a form. Given my advanced understanding of garbage collection etc (i.e. none, until yesterday), I never thought to clear up behind me, as in the vast majority of cases, the subscribers also live for the lifetime of the application.

I’ve fiddled around a while with Dustin Campbell’s WeakEventHandler, but it doesn’t work with anonymous delegates (not for me anyway).

Is there anyway out of this problem? I really would like to avoid having to copy-paste boiler-plate code all over the shop.

(Oh, and don’t bother with asking me WHY we are creating and destroying controls all the time, it wasn’t my design decision…)

(PS: It’s a winforms application, but we’ve upgraded to VS2008 and .Net 3.5, should I consider using the Weak Event pattern?)

(PPS: Good answer from Rory, but if anyone can come up with an equivalent to the WeakEventHandler which avoids me having to remember to explicitly UnLink/Dispose, that would be cool…)

EDIT I must admit that I worked around this problem by “recycling” the controls in question. However the workaround has come back to haunt me as the ‘key’ I was using is apparently non-unique (sob). I’ve just discovered other links here (tried this – seems to be a bit too weak – GC clears delegates even if target is still alive, same problem with s,oɔɯǝɹ answer below), here (forces you to modify publisher, and doesn’t really work with anonymous delegates) and here (cited-as-incomplete by Dustin Campbell).

It occurs to me that what I’m looking for may be semantically impossible – closures are designed to ‘hang around even after I’m gone’.

I’ve found another workaround, so I’ll stick with that, pending a voice from the gods.

Answer 1

I know that this question is ancient, but hell – I found it, and I figure that others might as well. I’m trying to resolve a related issue, and might have some insight.

You mentioned Dustin Campbell’s WeakEventHandler – it indeed cannot work with anonymous methods by design. I was trying to fiddle something together that would, when I realized that a) in 99% of cases I’d need something like this his original solution would be safer, and b) in those few cases where I have to (note: have to, not “want to because lambdas are so much prettier and concise”) it’s possible to make it work if you get a little clever.

Your example seems like exactly the kind of one-off case where getting a little tricky can result in a fairly concise solution.

public static class Linker {
    public static void Link(Publisher publisher, Control subscriber) {
        // anonymous method references the subscriber only through weak 
        // references,so its existance doesn't interfere with garbage collection
        var subscriber_weak_ref = new WeakReference(subscriber);

        // this instance variable will stay in memory as long as the  anonymous
        // method holds a reference to it we declare and initialize  it to 
        // reserve the memory (also,  compiler complains about uninitialized
        // variable otherwise)
        EventHandler<ValueEventArgs<bool>> handler = null;

        // when the handler is created it will grab references to the  local 
        // variables used within, keeping them in memory after the function 
        // scope ends
        handler = delegate(object sender, ValueEventArgs<bool> e) {
            var subscriber_strong_ref = subscriber_weak_ref.Target as Control;

            if (subscriber_strong_ref != null) 
                subscriber_strong_ref.Enabled = e.Value;
            else {
                // unsubscribing the delegate from within itself is risky, but
                // because only one instance exists and nobody else has a
                // reference to it we can do this
                ((Publisher)sender).EnabledChanged -= handler;

                // by assigning the original instance variable pointer to null
                // we make sure that nothing else references the anonymous
                // method and it can be collected. After this, the weak
                //  reference and the handler pointer itselfwill be eligible for
                // collection as well.
                handler = null; 
            }
        };

        publisher.EnabledChanged += handler;
    }
}

The WPF Weak Event pattern is rumored to come with a lot of overhead, so in this particular situation I wouldn’t use it. Furthermore, referencing the core WPF library in a WinForm app seems a little heavy as well.