Will Whidbey make MFC/WinForms Interop easier?

[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<typenam e FORM> where FORM : System::Windows ::Forms::Contro l
ref class CControlWrapper : public CWnd
{
private:
// lots of magic code to make a System::Windows ::Forms::Contro l object
look like a CWnd
protected:
FORM* m_WinFormContro l;
};

ref class CMyControl : public CControlWrapper <MyApp::MyUserC ontrol>
{
public:
void Method1() {
m_WinFormContro l->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

[Ronald Laeremans [MSFT]]

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

"Dan Smith" <J_************ @HoTMaiL.com> wrote in message
news:O3******** ******@TK2MSFTN GP09.phx.gbl...

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<typenam e FORM> where FORM : System::Windows ::Forms::Contro l
ref class CControlWrapper : public CWnd
{
private:
// lots of magic code to make a System::Windows ::Forms::Contro l object
look like a CWnd
protected:
FORM* m_WinFormContro l;
};

ref class CMyControl : public CControlWrapper <MyApp::MyUserC ontrol>
{
public:
void Method1() {
m_WinFormContro l->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

[Dan Smith]

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

"Ronald Laeremans [MSFT]" <ro*****@online .microsoft.com> wrote in message
news:ed******** ******@TK2MSFTN GP10.phx.gbl...

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

"Dan Smith" <J_************ @HoTMaiL.com> wrote in message
news:O3******** ******@TK2MSFTN GP09.phx.gbl...

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<typenam e FORM> where FORM : System::Windows ::Forms::Contro l
ref class CControlWrapper : public CWnd
{
private:
// lots of magic code to make a System::Windows ::Forms::Contro l object look like a CWnd
protected:
FORM* m_WinFormContro l;
};

ref class CMyControl : public CControlWrapper <MyApp::MyUserC ontrol>
{
public:
void Method1() {
m_WinFormContro l->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

[Ronald Laeremans [MSFT]]

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

Ronald

"Dan Smith" <J_************ @HoTMaiL.com> wrote in message
news:Ok******** ******@TK2MSFTN GP09.phx.gbl...

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

"Ronald Laeremans [MSFT]" <ro*****@online .microsoft.com> wrote in message
news:ed******** ******@TK2MSFTN GP10.phx.gbl...

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

"Dan Smith" <J_************ @HoTMaiL.com> wrote in message
news:O3******** ******@TK2MSFTN GP09.phx.gbl...

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<typenam e FORM> where FORM : System::Windows ::Forms::Contro l
ref class CControlWrapper : public CWnd
{
private:
// lots of magic code to make a System::Windows ::Forms::Contro l object look like a CWnd
protected:
FORM* m_WinFormContro l;
};

ref class CMyControl : public CControlWrapper <MyApp::MyUserC ontrol>
{
public:
void Method1() {
m_WinFormContro l->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

[Stephan Schaem]

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

"Ronald Laeremans [MSFT]" <ro*****@online .microsoft.com> wrote in message news:ed******** ******@TK2MSFTN GP10.phx.gbl...

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

"Dan Smith" <J_************ @HoTMaiL.com> wrote in message
news:O3******** ******@TK2MSFTN GP09.phx.gbl...

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<typenam e FORM> where FORM : System::Windows ::Forms::Contro l
ref class CControlWrapper : public CWnd
{
private:
// lots of magic code to make a System::Windows ::Forms::Contro l object
look like a CWnd
protected:
FORM* m_WinFormContro l;
};

ref class CMyControl : public CControlWrapper <MyApp::MyUserC ontrol>
{
public:
void Method1() {
m_WinFormContro l->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

[Ronald Laeremans [MSFT]]

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

"Stephan Schaem" <ss*****@seriou smagic.com> wrote in message
news:uo******** ******@TK2MSFTN GP11.phx.gbl...

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

"Ronald Laeremans [MSFT]" <ro*****@online .microsoft.com> wrote in message

news:ed******** ******@TK2MSFTN GP10.phx.gbl...

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

"Dan Smith" <J_************ @HoTMaiL.com> wrote in message
news:O3******** ******@TK2MSFTN GP09.phx.gbl...

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<typenam e FORM> where FORM : System::Windows ::Forms::Contro l
ref class CControlWrapper : public CWnd
{
private:
// lots of magic code to make a System::Windows ::Forms::Contro l object look like a CWnd
protected:
FORM* m_WinFormContro l;
};

ref class CMyControl : public CControlWrapper <MyApp::MyUserC ontrol>
{
public:
void Method1() {
m_WinFormContro l->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