By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,926 Members | 1,839 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,926 IT Pros & Developers. It's quick & easy.

Will Whidbey make MFC/WinForms Interop easier?

P: n/a
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
Nov 16 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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**************@TK2MSFTNGP09.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<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

Nov 16 '05 #2

P: n/a
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**************@TK2MSFTNGP10.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**************@TK2MSFTNGP09.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<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


Nov 16 '05 #3

P: n/a
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**************@TK2MSFTNGP09.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**************@TK2MSFTNGP10.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**************@TK2MSFTNGP09.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<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



Nov 16 '05 #4

P: n/a
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**************@TK2MSFTNGP10.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**************@TK2MSFTNGP09.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<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


Nov 16 '05 #5

P: n/a
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*****@seriousmagic.com> wrote in message
news:uo**************@TK2MSFTNGP11.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**************@TK2MSFTNGP10.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**************@TK2MSFTNGP09.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<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



Nov 16 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.