The problem both Josh and I encounter is something to do with DP value inheritance on those visuals drawn in the adorner layer using visual layer programming technique, first off I don't agree with Josh's comments about the visual tree and adorner layer. Actually those visuals drawn in the adorner layer are also part of the visual tree if you programme it in the proper way, the reason the inherited DP values are "invisible" to the adorning visuals should be something to do with how we add those visuals in the adorner layer as Ian Griffiths suggests. The following code is a simplified version of the custom Adorner which can host a single UIElement properly:

The above code demonstrates both on how to define visual tree using visual layer programming and how to define the logical tree. When defining the visual tree, you should override GetVisualChild method and VisualChildrenCount property to enable proper indexing on the hosted visuals, optionally you can make the call to Visual.AddVisualChild method to establish the child-parent relationship for the visual tree of the custom element. this call is mandatory if you are hosting single visual, and you want to enable dependency property inheritance and UI interaction on this visual. If you are hosting multiple visuals, you can use the VisualCollection to establish the children-parent relationship. When defining the logical tree, you should override the LogicalChilden property, and if you are adding single element, you should call the FrameworkElement.AddLogicalChild method, and if you are adding multiple elements, you can use UIElementCollection to store the logical children.

So If we use UIElementCollection, the above code can be re-written as follows:

As the final words, since UIElementCollection enables both visual tree level and logical tree level programming, It's more appropriate when defining new content model for you cutsom control, because ContentControl, ItemsControl, HeaderedContentControl, and HeaderedItemsControl all don't fit into your peculiar need. But if you want to programme at the visual level to gain better performance, VisualCollection is more appropriate. And also note that if you just hosing single element, VisualCollection and UIElementCollection all seem a bit overkilled, just mind you, a collection object which contains a single object takes much more memory than the single object itself, so when hosting single element, the first code sample makes more sense.

Last but not least, my greatest thanks is given to Ian Griffiths for his wonderful tips on Visual.AddVisualChild method and overriding LogicalChildren property.

Someone asks in MSDN forum on how to host top-level form in WPF, To be pedantic, the System.Windows.Window in WPF is "big" top-level hwnd indeed, and you cannot put another top-level hwnd into this hwnd, this is not a WPF limitation, this is actually a limitation imposed by Win32, but Win32 does allow you to add child hwnds, you can work around this limitation by "transforming" the top-level hwnd into a child hwnd, I've created a custom control which can do this trick:

using System; using System.Windows; using System.Windows.Interop; using System.Windows.Forms.Integration; using System.Runtime.InteropServices;

The above code also demonstrates how to make custom HwndHost in WPF, note that in the setter of Child property, I've checked to see if the layout is already done, this is important because BuildWindowCore method will be called during the layout pass, and it's meaningless to set the Child property after BuildWindowCore is made. and also note that I make a call to WindowsFormsHost.EnableWindowsFormsInterop() method, this is also pretty important if you want the hosted Form object to properly get notified with the keyboard related messages, because Windows Forms and WPF have different way of implementing message pumping. If you want to know all the details related to how the message loop interop between Windows Forms and WPF works, you can read the WPF documentation article: Windows Forms and WPF Interoperability Input Architecture.

The usage of FormHost in XAML is pretty straightforward as the following XAML snippet domonstrates:

Ben Constable just blogs about another elegant way to listen to dependency property change, the trick here is using DependencyPropertyDescriptor, imagine that you have a Label called myLabel, and you want to get notified when it's ContentProperty is changed, then you can do something like the following:

The other ways in WPF that you can use to listen to property change is to subclass an existing Control, and override the metadata of a dependency property whose property change you want to listen to, when you do so, you need to specify a PropertyChangedCallback which a delegate to your property change event handler, or instead of using PropertyChangedCallback, you can override the OnPropertyChanged method, and place your logic there, as a bonus, you can get additional information things like which property is changed by examining the value of passed-in DependencyPropertyChangedEventArgs argument's Property property.