Partager via

Introducing Windows Forms - WPF Interoperability

  • Article

(Tunes I'm listening to while I blog: Sun Kil Moon, "Ghosts of the Great Highway")

So you've been developing Windows Forms applications since .Net Framework 1.0 right?  And now you've been totally jazzed by all the buzz surrounding Windows Presentation Framework (WPF) formerly known as "Avalon".  You may ask yourself, "how do I work this?"...Sorry couldn't resist the Talking Heads reference.  Seriously, you are probably wondering exactly how you can leverage you existing Windows Forms code base and still take advantage of key functionality provided by WPF.  Well we've got your answer right here baby!

The Windows Forms team is currently developing technology that will allow you to build hybrid applications that consist of both Windows Forms and WPF controls on the same "form".  This works from both application perspectives.  This means that you can build Windows Forms applications that have forms that contain both WF controls and WPF controls.  Conversely, you can build WPF applications that contain windows or pages that consist of both WF and WPF controls.  Internally we have codenamed this project "Crossbow".  We just got really tired of saying "Windows Forms and WPF Interoperability".  Why Crossbow?  Well, "Avalon" means "place of apples" so I had an image in my head of Swiss legend William Tell shooting the apple off of his son's head using his crossbow (yes he used a crossbow and not a traditional bow and arrow) and thus Crossbow.

This technology is part of the WPF code base but is not currently shipping with the WPF redist.  In fact, it is shipping in "tech preview" form in the WinFX SDK.  It is contained within an assembly named "WindowsFormsIntegration.dll" and lives in the "C:\Program Files\Reference Assemblies\Microsoft\Avalon\v2.050215" directory.  (Note that the version number used in this sample path assumes that you are running the September CTP bits, a.k.a. "PDC bits").

Basically, this consists of two controls that enable this hosting model.  The WindowsFormsHost control is used to place Windows Forms controls on a WPF window or page and the ElementHost control allows hosting of WPF elements on a Windows Forms form.  It was a conscious design decision to limit these controls to hosting only ONE top level control.  This does not mean that you cannot host Windows Forms UserControls in the WindowsFormsHost because the UserControl will act as the top level control and the composite controls are child controls so this does not violate the limitation.  However, if you want to have to top level controls such as a WF Label and a TextBox appearing on a WPF page (without wrapping these controls up in a UserControl) then you will have to use two WindowsFormsHost controls, one for each WF control.  Similarly, in the Windows Forms application case, you must use one ElementHost control for each top level WPF element that you want to host in your form.  However, you can have a WPF visual tree defined using XAML that may contain multiple child controls and this can be hosted in a single ElementHost control.

Will this stuff ship with WPF?  Uh, no.  This technology is scheduled to ship with the next release of Visual Studio, codenamed "Orcas".  But it will remain in the WinFX SDK and will most likely be in beta form by the time WPF ships.  For more details, you can check out the slides that I presented at the PDC on the topic.

I will follow up with a series of entries that deal specifically with coding examples of how to use these controls in detail and some of the little "gotchas" that you need to know about.  In the meantime, you should download the September CTP of the WinFX Runtime components and the Beta1 of the WinFX SDK and start playing around with the stuff.

Comments

  • Anonymous
    October 07, 2005
    The comment has been removed
  • Anonymous
    October 10, 2005
    I don't think so. Beta2 is coming up fast and that build will be based on .Net 2.0 RTM.