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
WPF Disciples 
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
I apologize if this is not allowed to post here (I did not see it being specified anywhere): I have a WPF project that my company would like to outsource, and I would like to know if people on here (both authors and readers) would be interested in knowing the details of it.
If this is not allowed, moderators please delete my post, I apologize in advance. Just please let me know.
If anyone is interested in getting details about the WPF project send me a mail at gmagana at gmail dot com.
Thanks!
Nice..Thank’s Your Articel
Hello bro.
I the new user.
Scandal is assured it,news Foto
http://kristenchenowethnude.blogspot.com
[…] the acronym formed, which helps in thinking about UIElement – “LIFE begins at UIElement“. Possibly related posts: (automatically generated)#11 – Commandsjava.awt.RobotWhy […]
hey! Loved ur article man!
The mnemonic is just awesome!
Hi… it´s a interesting blog, like me, I also have a nice blog, here you can find great deals if you ever want to make vacation in Denmark. Greetings from Europe
Nice and thanks
Thank you very much.
Your blog is very interesting and exciting, if you want to learn about the Vietnam country, please visit my blog.Hopefully this will be helpful for you.
Reblogged this on Vietnamcountry.
A topic attracted the readers.
With havin so much content and articles do you ever run into
any issues of plagorism or copyright violation? My blog has a lot of completely unique
content I’ve either authored myself or outsourced but it looks like a lot of it is popping it up all over the web without my agreement.
Do you know any ways to help reduce content from being ripped off?
I’d really appreciate it.
Un discours de mariage rédigé en bon français, foncez!
This info is worth everyone’s attention. When can I find out
more?
Is anyone available or can recommend a vb.net programmer that can write a small application to intercept when another WPF application displays a component and then subscribe to its event and change one of its properties?
Good compensation provided.
Contact me at: pholan at hotmail dot com
Attraction Marketing Seminars
FrameworkElement vs. FrameworkContentElement | WPF Disciples
http://Tronsr.Org/Index.Php?P=/Discussion/1621916/Just-Want-To-Say-Hi
FrameworkElement vs. FrameworkContentElement | WPF Disciples
taking a Break in A relationship
FrameworkElement vs. FrameworkContentElement | WPF Disciples