.NET Framework architects continue to disappoint me.
VS.NET2005's WinForms designer, while glamorous, tends to create an increasingly complex web of EventHandler/Delegate dependencies between the top container and the components it contains as well as among components themselves.
Typically, this sort of problem is solved by applying the Command design pattern but .NET 2.0 doesn't have a built-in support. I have no idea why a feature GUI programmers considered essential since the MacApp days is not in .NET.
So I began writing one this morning that used .NET's existing event and delegate support. It took me little time to run into the strong delegate reference problem which just created more work for me. And it looks like .NET 2.0 won't have built-in support for weak delegates although enough people both inside and outside Microsoft have noted the problem.
After more experiments, I've concluded that independent implementation of weak delegate makes little sense because .NET's event and delegate implementation is too deep a level and sealed too tightly. Instead, I am going to abandon using delegates, rigging an interface-based command microframework instead.
A last bit of rant while I am at it. I've found .NET code like below bewildering. First, 'EventHandler' receives an instance of the calling class mysteriously. Second, keyword 'event' turns 'Testing' into a weird collection-like object. And what's with having to instantiate EventHandler to remove an EventHandler?
public event EventHandler Testing;
Testing -= new EventHandler(Testing_Called);