Here’s a few WPF-related irresponsible statements for you…

• You can have a static event. But you can’t have a static class/member implement an interface. So, when one of the members of the interface happens to be an event—well…
• The Markup Extension x:Static is the first bit of WPF that is involved in runtime, XAML-parsing exceptions. These exceptions lead me to conclude that WPF ‘prefers’ a Static Resource that maps to a CLR object (with its parameter-less default constructor) than a Static CLR class called by {B``inding Source={x:Static myns:MyStaticThing.MyProperty}, Path=MySubProperty}.
• I’m swaggeringly sure that WPF prefers {``x:Static myns:MyStaticThing.MyProperty} over {B``inding Source={x:Static myns:MyStaticThing.MyProperty}, Path=MySubProperty}.The general ‘principle’ here (which can be counterintuitive) is that static is “bad” in a WPF application (but this does not mean StaticResource is bad—as DynamicResource is very “bad” as far as I’m concerned by the way). Okay, that wasn’t a “principle”—just rambling…

I just read somewhere on the internet that each WPF XAML element declaration instances a new object—so that’s way more new instancing than hanging on to static references. I also read/heard somewhere that much of .NET is optimized for “object creation” instead of hanging on to static bits of memory.

rasx()