Partager via

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 .

Comments

  • Anonymous
    January 17, 2004
    This is a longshot, but, any idea about what the future of WTL is wrt .Net?
  • Anonymous
    January 18, 2004
    Thanks for the update.

    How about the other way? Using MFC-based CMyLegacyCtrlIdRatherNotRewrite or CThridPartyCtrlThatHasntBeenPorted in a WinForms application?
  • Anonymous
    January 20, 2004
    Senkwe: I will see what I can find out about our plans for WTL and let you know.

    Daniel: Here is what Anson Tsao had to say about your question:

    The problem with supporting it is that MFC extension DLLs can only be supported by MFC applications, so it’s difficult to have a general solution that will work with allowing any MFC controls to be hosted in non-MFC based WinForms applications. On the other hand, you can host MFC windows in WinForms either as an ActiveX control or subclassing a .NET control’s HWND with the MFC control.