Windows Forms - MFC Interop: What's new in Whidbey?

  • Article

In response to a comment on my previous post on this topic, I emailed some folks internally to find out what new is planned for Whidbey in the area of Windows Forms - MFC interop. Here is what Anson Tsao, a Program Manager on the VC++ team, had to say:

WinForms (v1.1+) supports being hosted in MFC 7.1 and above as ActiveX controls (through either IJW or CLRHosting - not recommended). However, there's nothing specific in MFC to make this easy to do. In Whidbey, we are building direct support in MFC for WinForms interop. This will require compiling part or all of the MFC application with the /CLR option. This is our strategy for helping existing MFC applications take advantage of .NET and in the future Longhorn WinFX, and we are doing a lot of work in Whidbey to make this scenario 'just works'.

With C++/CLI, compiling MFC application with /CLR is significantly easier than before, because there're fewer conflicts with keywords etc.

For Whidbey, we will support the following:

  • Using WinForms Controls as child windows and controls
  • Using WinForms Controls as MDI child windows - see update below
  • Using WinForms Forms as modal/modeless dialogs
  • Using WinForms Forms/Controls as MFC CViews, with command routing

We are providing a set of .NET interfaces that, when implemented on WinForms Controls, can be used to participate in MFC command routing, and be part of the MFC doc/view infrastructure. These controls can be implemented in any .NET language.

Update regarding the 2nd bullet (quoting from a source within Microsoft):

MFC in VS 2005 supports only hosting a Winforms control as a view (rather, child of the view but of same size as view). So the Winforms control can be a child of the MFC created MDI child. But the form being a direct MDI child is not supported. For more information, please see the document on https://msdn2.microsoft.com/en-us/library/6xfx8bsa(vs.80).aspx .