FrameworkElement vs. FrameworkContentElement

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

Why WPF is ready for LOB

A rather interesting, though horribly misnamed, thread started on the WPF Forum. The “Why WPF is not ready for LOB” thread contains quite a few insightful perspectives on the topic of WPF’s viability for line-of-business (LOB) development. The thread also contains links to blog posts that carry the discussion out further.

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 in WPF – WPF Disciples tips and tricks

It is proven that we software developers spend more time debugging than actually writing code. Guess what?!! WPF is no different… We have to debug and debug and debug! So the WPF Disciples decided to make a list of articles that can help WPF developers make the debugging process easier.

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.

{Binding Path=Height, Converter={local:DebugBinding}}

– 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.

<TextBlock Text=“{Binding Path=Caption, diagnostics:PresentationTraceSources.TraceLevel=High}” />

– 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.

Handling and Reporting WPF Data Binding Validation Errors and Exceptions

This last month Karl has been obsessed with WPF business object data binding, and the .NET 3.5 support for the IDataErrorInfo interface.

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.

WPF Disciples has a 3D blogroll

Josh has been at it again. This time he took all of the WPF Disciple member bio’s and turned it into an interactive 3D blogroll! Check it out here.

WPF Disciples in 3D

Welcome to the blog of the WPF Disciples group! This is the first post to our group’s blog. Recently, Josh Smith posted on his blog about an application that displays the items of an ItemsControl in a 3D panel. You can check it out here.

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)