Can't We All Just Get Along?

(Blogging Tunes: Jethro Tull - "Aqualung")

Sorry to drop the highly overused  Rodney King quote on you, but it seems to fit here.  I wanted to take some time to pop up a level as it were to discuss interoperability between Windows Forms and WPF at a much higher, philosophical level.

First of all, you should think of this subject area more as a co-existance strategy.  I say that because sometimes the term migration strategy gets thrown around as well and I want to be clear about what our plans are focusing on.  We are currently NOT planning a strategy whereby we ship a migration wizard that will take your Windows Forms application and magically spit a WPF application out the back.  That approach is simply not in the cards for us.  Some of the reasons for this are the fact that it is incredibly difficult (if not impossible) to get this right, and from talking with customers about this, the feedback has been overwhelming that migration is not the way to go.

Also, don't draw parallels between this technology and the chasm of VB6 vs. VB.Net for example.  There is little to no comparison.  When we speak about interoperability (co-existance) with respect to Windows Forms and WPF, we are talking about the ability to have applications contain assets from both Windows Forms and WPF even within a single executable.  Both technologies are based on managed code and the CLR and the differences are primarily related to the underlying redering engines, different control sets and declarative capabilities.

The challenges here are related to the fact that we have two different message loops running (one for WPF and one for Windows Forms) and that can complicate things.  Furthermore, it can sometimes make things like keyboard functions, focus management and eventing challenging.  It is our goal however to ensure that we address all of these issues if at all possible.  These are areas that we are currently looking at and so far we have good solutions for most of these.  Ultimately, we will make sure to clearly document any scenarios that will not be supported, but our hope is that this list will be incredibly small.

Once again, to be clear, our approach is to make sure that you can have a Windows Forms application that can contain WPF controls (elements) on a Windows Form Form that also contains Windows Forms controls and also to allow complete WPF Windows or Pages to be launched from a Windows Forms application.  Conversely, we also will have support for WPF applications that contain Windows Forms controls (DataGridView, WebBrowser, etc.), Windows Forms-based UserControls and custom controls as well as ActiveX controls.

That's all for now.

Comments

• Anonymous
  January 17, 2006
  Do I understand from what you were saying that we can NOW host an ActiveX control in WPF (which I have working just fine) but we cannot YET host something like a WindowsForms WebBrowser control in WPF but we will be able to one day ? (The latter certainly does not seem to work for me right now, sadly).