Will Whidbey make MFC/WinForms Interop easier?

  • Thread starter Thread starter Dan Smith
  • Start date Start date
D

Dan Smith

Right now the only way to use a WinForms control in MFC is to enable COM
Interop for the control and use it in MFC as you would any ActiveX control.
While this works, COM Interop is a pain, and an ActiveX control isn't as
straight-forward as a CWnd-derived object. It also means that I have to
split my code into two projects. Going the other way (using MFC in
WinForms) is only possible by exposing MFC objects as ActiveX controls,
which probalby means adding ATL to an existing MFC project.

Is any of this going to be easier/cleaner in Whidbey? What I have in mind
is something like (I'm sure I don't have all the new syntax right):

generic<typename FORM> where FORM : System::Windows::Forms::Control
ref class CControlWrapper : public CWnd
{
private:
// lots of magic code to make a System::Windows::Forms::Control object
look like a CWnd
protected:
FORM* m_WinFormControl;
};

ref class CMyControl : public CControlWrapper<MyApp::MyUserControl>
{
public:
void Method1() {
m_WinFormControl->Method1();
}
};

This would make using CMyControl as easy as any other CWnd-derived object;
which would make it much easier to integrate WinForms controls into an
existing MFC application. Going the other way would be nice too, as there
are MFC-based controls available (I'm specifically thinking of
http://codejock.com).

Can anybody comment?

Thanks,
Dan
 
Yes, our plans are for more explicit support for integrating MFC and Windows
Forms in the Whidbey release.

It is still too early to share any preliminary design of that feature.

Ronald Laeremans
Visual C++ team
 
OK...I'll be anxiously waiting to see how this is supported. Glad to see
it's "on ths list". Is this not a "sexy" enough feature to make it onto
things like PDC presentations and .NET blogs?

Dan
 
It is too early in the gestation phase of this feature to have made it into
the PDC, or into current BLOG entries.

Ronald
 
Related to this, did microsoft develop some scenario on what it takes to port
a XP native C++ multimedia application to Longhorn?

My area of interest are:

- Taking advantage of the new UI features (How to Replace Win32)
- Taking advantage of the new multimedia API (How to Replace Directshow)
- Keep tight integration of all API: Mainly how COM Direct3D tightly integrate with
the new UI, media services and WinFS.

Their is allot of information and its easy to get 'lost' and spend days reading very low level info.

Thanks for any pointers...

Stephan
 
Hi Stephan,

Since this really is a question for the Longhorn team, I think you would get
a better answer asking in one of the Longhorn forums, or in the DirectX
forums that deal with the current technology.

Ronald
 
Back
Top