Jason: No Benchmarks, but then, when you're updating your UI from a background thread, that's hardly a perf-issue.
I am doing some caching on the proxy side of things to make sure that I don't re-get all attributes of a method on every call to it, but only on the first call.
basically that means that the "GetCustomAttributes() method is called once per virtual method on a form, which should definitely save some cycles.
It also ignores the "WndProc" loop totally.
I have not used this yet on a real application, but after a bit of smoke testing it seems to be ok (that is - no smoke is coming out of my machine when I test it!)
That's a good idea - but maybe more flexible to refactor to a method that accepts a delegate (by which you can supply an anonymous one)?
hammet: no, he didn't mention it.
Looking at the code, it certainly looks like it will do the job!
I still prefer using my way because it allows very easy out of the ox extensiblity with intercepting attributes with just one single class.
Thanks for the update!
A few years ago I built a framework in .NET 1.1 to be used by former web programmers (with no previous knoledge of threading or Windows Forms) that had a class Event with a Fire method that took the delegate to fire and, if not null, iterated though the invocation list (Delegate.GetInvocationList()) and, if the Delegate.Target was of a type implementing System.ComponentModel.ISynchronizeInvoke Interface, it would call Traget.Invoke; otherwise Delegate.DynamicInvoke was used.