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 thatstatic
is “bad” in a WPF application (but this does not meanStaticResource
is bad—asDynamicResource
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.