I'm blogging to:
Soul Coughing
Irresistable Bliss

What's the deal?  I tried to use an ActiveX control in a WPF application using XAML, but no worky!  Yep, 'fraid so mis amigos, we have a bug.  Here's the story.  Say you want to host one of these controls in a WPF application and you want to use XAML to do so.  You would code something like this:

<?Mapping XmlNamespace="wfi" ClrNamespace="System.Windows.Forms.Integration" Assembly="WindowsFormsIntegration"?>
<?
Mapping XmlNamespace="wf" ClrNamespace="System.Windows.Forms" Assembly="System.Windows.Forms"?>
<?
Mapping XmlNamespace="ax" ClrNamespace="AxWMPLib" Assembly="AxInterop.WMPLib"?>
<
Window x:Class="AvalonApplication26.Window1"
     xmlns=http://schemas.microsoft.com/winfx/avalon/2005
     xmlns:x=http://schemas.microsoft.com/winfx/xaml/2005
     xmlns:wfi="wfi"
     xmlns:wf="wf"
     xmlns:ax="ax"
     Title="AvalonApplication26"
     >
     <
Grid>
          <
wfi:WindowsFormsHost>
               <
ax:AxWindowsMediaPlayer/>
          </
wfi:WindowsFormsHost>
     </
Grid>
</Window>

Then you would run the app with the utmost of optimism, hardly able to contain yourself as you wait for the window to come up with your MediaPlayer control sitting pretty...but alas you see:


Yo, what gives "homes"?  Okay, so here's the deal...  There is an issue with WindowsFormsHost that deals with the timing of when window handles are created.  Specifically in the case of ActiveX controls, the Window handle is already created when we try to parent the control to the WindowsFormsHost control and our logic assumed that it would not be created yet, therefore we don't set its parent correctly.  Ultimately, this results in a case where the ActiveX control is not properly parented to the WindowsFormsHost.  Easy fix, but you won't see it until the next CTP release.

However, there is a simple workaround for this issue...do it all via code instead of XAML.