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

If you have something to say about WPF for LOB that has not yet been introduced on that thread, please take the time to share with the rest of us. This is an important topic for WPF at this point in its life.

Debugging DataBinding

– Marlon Grech wrote a Markup Extension that you can use in your DataBinding that will auto magically break in Visual studio so that you can see your binding value. Your markup would look similar to this. read more.

– Beatriz Costa blogged on how you can enable tracing in your data binding by using a new WPF Feature of .Net 3.5. So basically you can do something like this in your data binding… read more.

– Corrado Cavalli wrote another article on the PresentationTraceSources feature of .Net 3.5 giving some more insights.

Tools, tools and more tools…

Snoop is a tool that can you can use to hook to your running WPF application and browse the Visual Tree of the application. You can also inspect and edit the properties, inspect routed events (including the elements that handle them) and magnify sections in the UI.

Mole is a tool that integrates with Visual Studio (also available as a standalone app in the near future) that lets you inspect the Visual Tree of your application, inspect and edit properties, view the XAML for selected elements, preview a snapshot image of individual elements and much much more .

Performance Profiling Tools for WPF. These are a set of tools provided by Microsoft that allow you to analyze the run-time behaviour of your application and determine the types of performance optimizations you can apply .

Reflector is the class browser, explorer, analyzer and documentation viewer for .NET. Reflector allows to easily view, navigate, search, decompile and analyze .NET assemblies in C#, Visual Basic and IL. There is also a plugin related to WPF for Reflector called BAMLViewer which enables the user to see the XAML embedded in the assemblies being analayzed.

You may also want to write your own tool that integrates with Visual Studio to do your own thing, here is a brilliant article from Karl Shiflett on how to create a debugger visualizer.

More tips and tricks…

– Josh Smith wrote a very interesting article where he gives some tips on debugging databinding and also on how to dig into exceptions that are thrown on runtime (ex: invalid StaticResources ) read more.

– Shawn Burke blogged on how one can configure Visual Studio to debug .Net framework source code. Read more ….

Do you have any other tips/tricks of debugging WPF applications? then post a comment and share your knowledge with the rest of the WPF Community.

He posted an informative article entitled Handling and Reporting WPF Data Binding Validation Errors and Exceptions.

This article, which includes a Silverlight video, challenges the reader to fully understand what messages the WPF data binding pipeline routes to the UI and how to report/handle exceptions thrown during the data binding process. It includes a demo application that throws exceptions at different locations in the source object and how to create robust code that can deal with them gracefully.

A custom value converter and Validation.ErrorTemplate combine to provide a developer with the capability to display inner exception messages should they be routed to the UI. Additionally, this article explains why using a trigger to set a ToolTip for displaying an error message may not be a good practice.

One thing that he did not mention is that the demo application contains pictures of several WPF Disciples. As you watch the images move along the carousel, you will see Karl Shifflett, Marlon Grech, Mike Brown, Sacha Barber, Josh Smith, and Dr. WPF. Basically, all of the people who currently have a bio on this blog will fly by you in 3D when you run the program. The ultimate geek accomplishment!

(click on the image to see the full-size version)