FrameworkElement (FE) derives from UIElement. FrameworkContentElement (FCE) derives from ContentElement. Since the framework is not built on a language that supports multiple inheritance (and thank god for that!), the divergence was necessary. There are parts of ContentElement that you wouldn’t want in every FE and there are parts of UIElement that you wouldn’t want in every FCE.
FCE basically exists to support the text formatting engine (which can be found in the MS.Internal.Text namespace). There are a few non-text classes that derive from FCE, but they do this just to be lightweight.
The goal was to make the programming experience for dealing with an FE and FCE as similar as possible. If anything, I think this makes the framework *more* elegant.
You can think of an FCE as having everything an FE has except support for layout/rendering. Of course, this is no small feature and you certainly would not want that kind of overhead in every text element. Imagine the perf if you tried to render every textual stroke using WPF’s layout engine… text is far too complex.
True, it’s weird to see the exact same properties, methods, interfaces, events, etc, defined on two completely different base classes. But I guess my general response is a big shrug. As long as Microsoft is willing to maintain the code, I don’t have a problem with it. (And in truth, much of the code shared between the classes is codegen’d anyway during the build process, so its really not that hard for them to maintain… clever chaps!)
Sidenote: IFE vs. LIFE: A mnemonic we used to use is “LIFE begins at UIElement”. That is to say, every UIElement supports Layout, Input, Focus, and Events. ContentElement gives you everything but the ‘L’. As such, the intersection of functionality between an FE and FCE is the IFE portion.
I recommend creating a helper class if you want to treat the IFE portion of framework objects in a polymorphic manner. It’s easy enough to implement… in fact, you can steal most of the implementation from the internal FrameworkObject class. 
Content Source: Dr. WPF
Source: thread
As Josh pointed out in the full thread, Stefan Dobrev at Telerik has implemented this approach for surfacing the features of a framework object in a generic manner. I just checked it out, and I agree that its a very clever solution! It’s a quality implementation of the type of helper class (well, in Stefan’s case, three helper classes and an interface) that I was recommending above. The usage scenario rocks! (However, I would probably change the interface name to IFrameworkObject to avoid confusion with the actual FrameworkElement class.)
[...] Dr WPF examines FrameworkElement vs. FrameworkContentElement [...]
[...] FrameworkElement vs. FrameworkContentElement (Josh Smith) [...]
Doc -
“(And in truth, much of the code shared between the classes is codegen’d anyway during the build process, so its really not that hard for them to maintain… clever chaps!)”
I was hoping you could shed some light on this for me. Exactly what role does code generation play in the development of the framework? How are the generating “much of the code…during the build process”?
Thanks,
Micah
More cowbell anyone?
Cowbell is my tool of choice. Stick to FitNesse.
A lot of dependency object-related code is repetitive, so any sort of macro system would be helpful. There are various ways to do this. Probably the best would be:
#region Dependency DSL
// This is a signifier to a sed (stream editor) or Perl script
// to snap-in the pieces
// it’s a plain old “data transformer”
// the DSL is commented out,
// and the signifier to the stream tool that you are using a DSL
// is the region blocks,
// which are customarily used for denoting codegen’ed stuff
#endregion
Contrast this to the weird way many structure their code, which is stupid and like so:
#regionDependencyProperties
#endregion
#region Properties
#endregion
Poor locality of reference. Studies show when reviewing code that programmers spend 50% of the time focused on variable declarations. Structuring your code this way makes you much less efficient than me, should you choose to do so. I’m not going to proselytize any further.
Micah,
Cowbell is my tool of choice. Stick to FitNesse.
A lot of dependency object-related code is repetitive, so any sort of macro system would be helpful. There are various ways to do this. Probably the best would be:
#region Dependency DSL
// This is a signifier to a sed (stream editor) or Perl script
// to snap-in the pieces
// it’s a plain old “data transformer”
// the DSL is commented out,
// and the signifier to the stream tool that you are using a DSL
// is the region blocks,
// which are customarily used for denoting codegen’ed stuff
#endregion
This is not unusual. QT has always required a meta-object-compiler (moc) to build a QT GUI app. It’s really somethin gyou need to account for in your build process. I’d hope the WPF folks approxcimate this approach.
Contrast this to the questionable way some structure their code:
#region DependencyProperties
#endregion
#region Properties
#endregion
Poor locality of reference. Studies show when reviewing code that programmers spend 50% of the time focused on variable declarations. Arguably, structuring your code this way makes you much less efficient than the other way, should you choose to do so.
SUPer