|
When the same thing is done inside an MFC ActiveX Control, the inner WinForms contents remain inactive. Any hint on how to make them active? Anyone faced similar thing?
|
|
|
|
|
Hi,
I created the menu and tool strip using winforms and created an container class using mfc and combined both after getting the portion of space for container the tool and menustrip bar is remain undrawn(or u can say it as blank) all controls which are placed are present but the part of area is remain unpaint.
can any one help me in this regard.
Thank you
Sunil
|
|
|
|
|
Hi Nish,
did you ever try the same thing for a MFC ActiveX? I'm running into major problems trying this.
I perform the same steps like hosting a WinForms control in a "stand-alone" application like described in your article or on MSDN here[^]. But it currently gives me two major problems:
(1) When starting a debug session Visual Studio (VS2005 by the way) starts our client app, which implements an ActiveX container, and loads the MFC WinForms ActiveX during startup. In the moment the client app is about to load the MFC WinForms ActiveX, Visual Studio freezes and hangs infinitely. Last messages I see in VS output window are that the CLR DLLs are being loaded. Looks like the LoaderLock problem described here[^]. But until now I didn't figure out how to prevent this LoaderLock. If the client app is started normally, means not via Visual Studio, it starts without problems.
(2) This leads to the next problem: When the MFC WinForms ActiveX is about to be displayed I get a crash in 'CWinFormsControl::InternalCreateManagedControl' (\vc\atlmfc\include\afxwinforms.inl). An analogous crash occurs when using the CWinFormsDialog template class instead of CWinFormsControl. Could be this known bug[^] which seems to be fixed with VS2005 Service Pack 1. But I didn't install and try it until now.
So do you have any experiences with hosting WinForms controls inside MFC ActiveXs?
Any help would really be appreciated!
cheers,
mykel
If they give you lined paper, write the other way!
|
|
|
|
|
1. I do not have AfxWinforms.h. What package is it a part of? Is it Dundas specific?
2. I am trying to populate a CWnd ( specifically a CView ) with a winform. Can this be accomplished in the same manner?
|
|
|
|
|
beausmom wrote: 1. I do not have AfxWinforms.h. What package is it a part of? Is it Dundas specific?
this is available only in VS2005. So, if you are using a previous version of Visual Studio, sorry then.
beausmom wrote: 2. I am trying to populate a CWnd ( specifically a CView ) with a winform. Can this be accomplished in the same manner?
You can use CWinFormsView for that.
"Some people believe football is a matter of life and death.
I'm very disappointed with that attitude.
I can assure you it is much, much more important than that. -- Bill Shankly"
|
|
|
|
|
Hi ,
I have given CLR Support to a VC8 MFC Application and am trying to use a .Net Windows in MFC Form. When i try to use
CWinFormsControl<system::windows::forms::form> m_ctrl1;
i get the following error
error C2143: syntax error : missing ';' before '<'
Can any one help
|
|
|
|
|
CWinFormsControl is a template class and you need to specify the template type parameter.
|
|
|
|
|
An alternative to setting the /clr flag for the entire project which needs to use .NET controls is to set the /clr flag for only the source file which uses the control (the dialog class source file for example).
- similar to doing it for the whole project, but with the following
differences
- move the #include <afxwinforms.h> from stdafx.h into the source file
where the control is being used
- leave /clr off for the project, but turn it on for the source file
- set exception handling to /EHa for the source file
- disable use of pre-compiled headers for the source file (since the
non-clr precompiled header won't be compatible with the clr source file)
- create a forward-declared inner class in the dialog class using the
control; this class is the control holder
- declare the control holder class in the source file, having it contain
the template instantiation (CWinFormsControl) class
- to use the control just refer to m_controlHolder.m_myControl
The holder class is necessary because you don't want to include the
afxwinforms header in the dialog's header or you'll pollute the rest of the
project.
|
|
|
|
|
Your message concerning the use of /clr only at the source file level is very interesting but it is not clear for me of how creating this class holder in the source file. Do you have a sample?
Régis
|
|
|
|
|
Does this work?... and if so could you please expand on how to do it. I am getting a "use of undefined type" error whenever I try to access m_controlHolder from unmanaged code. I can't declare it in the unmanaged code, however, because it requires CWinFormsControl, which requires CLR
|
|
|
|
|
Nice article! I was stuck on this until reading your article. Thanks
I built a sample MFC app with a Windows Forms control to test this technique and it worked great. I then put it on a machine which did not have the .NET 2.0 runtime installed. When I tried running, the app just silently exited.
I was hoping it would give an error to the user indicating that they need the .NET 2.0 runtime installed (like you get if you create a C# .NET app and try and run without the runtime installed).
Any ideas on this? Is there something which can be done to ensure this sort of error gets displayed instead of having the app just exit?
|
|
|
|
|
Hi, can an application of this type work with a .Net Framework older then 2.0?
Or does one have to force all users to upgrade to .Net 2.0?
|
|
|
|
|
I am running into some kind of deadlock situation using CWinFormsControl with a DataGridView. I can reproduce the problem with a simple SDI application and a CFormView that contains a CWinFormsControl<datagridview>, a couple of buttons, and a textbox. When focus leaves the CWinFormsControl<datagridview> to the buttons and/or text edit and then I put focus back into a cell in the grid, the application hangs. I can reproduce the problem every time and there is no external or 3rd party software involved. Has anyone else experience problems with deadlocks using MFC/.NET interop?
Jeff Boenig
|
|
|
|
|
The DataGridView doesn't really work smoothly in MFC applications using the CWinFormsControl and similar classes. It may be better to spawn off a WinForms form that contains the CWinFormsControl control from the MFC parent window (either a dialog or a view).
Regards,
Nish
|
|
|
|
|
Thanks for the reply Nish. It locks up very reliably. "Doesn't really work smoothly" is putting it mildly. For all intents and purposes, it doesn't work at all. I was also able to reproduce the same behavior with a 3rd party .NET grid control. It seems to me that there is a serious flaw lurking somewhere in the CWinFormsControl. I was trying to embed a .NET user control that contains a 3rd party grid on a tab of a tab control in MFC. I'm having to abandon that effort and popup a modal dialog instead. I'd still like to understand why it doesn't work, but your feedback is reassuring in the sense that I'm not the only one that has had trouble with it.
Thanks alot!
Jeff Boenig
|
|
|
|
|
Take a look at the comment labelled
"Editing a cell in DataGridView and alt-tabs away and then back causes hang"
Would it be something like that?
|
|
|
|
|
Hello Nishant,
Thanks for this excellent example illustrating interaction between winforms controls and MFC dialogs.
In your example however, the calling MFC application is compiled with /clr.
I am interested in exploring this interoperability with .NET controls. However, we have huge MFC code base and a lot of MFC extenstion dlls in our project. I do not want to compile the entire project or even a DLL with /clr (and have not been successful doing so anyway).
In a specific situation, I have an MFC extension dll which has a lot of dialogs which are invoked by client application.
In one of the dialogs, i compiled with /clr and embedded a winforms control in header file as in your example.
But since the header file is referenced by calling -unmanaged- client application i had to put the managed objects within the
#if MANAGED ....
CWinFormsControl<system::windows::forms::button> m_wfBtn;
#endif
but this in effect changes the memory layout of the object depending on where it is referenced from. What happens to member variables that are defined after the managed objects? I also noticed that there is stack corruption when the dialog is terminated.
any feedback is appreciated.
thank you raghu.
|
|
|
|
|
Sorry for the late reply, but you could try this :-
#ifdef _MANAGED<br />
CWinFormsControl^ ...<br />
#else<br />
void* ...<br />
#endif
A handle and a * take up the same number of bytes - so you won't change the layout.
Regards,
Nish
|
|
|
|
|
I've added a datagrid to MFC Dialog.
After binding data to datagrid, visible rowcount is still 0.
Why is it so?
The same databinding works fine in Winforms.
|
|
|
|
|
I also seem to have a problem using the DataGrid/DataGridView within a MFC dialog (using the CWinFormsControl< > template).
I create a DataSet from a Xml file and then set it to the DataSource. I also set the DataMember to the appropriate table name, but nothing is displayed in the grid view. I tried other various approaches, but nothing seems to work.
I have no problem setting this up in WinForms - it just won't display in MFC. I know the data's there because I can actually step right into it from the DataGrid object - it just won't display - the ColumnCount is still 0.
What's the problem? Have you or anyone else figured this issue out yet?
I just don't understand why this won't work.
|
|
|
|
|
I have managed to include a DataGridView in an MFC-based
dialog but I can't figure out how to put column headings
in it or populate it with data.
Anyone have any snippets of code that can do the trick ?
|
|
|
|
|
When the DataGridView is bound to a DataTable in a DataSet the rows
and columns for that DataTable do not appear in the Grid.
- This is failing because data-binding requires that the bound control have
a BindingContext. Normally the DataGridView would use the BindingContext
belonging to the Form it is on, but since the test application's DataGridView
is on an MFC dialog rather than on a Form it cannot use its parent's context.
To use data-binding with the MFC-hosted DataGridView will require that the
application either create and manage the BindingContext on its own or host
the DataGridView inside a ContainerControl (such as a UserControl) which will
manage a binding context for its children. You can find more information
about BindingContexts at: BindingContext Class (System.Windows.Forms) Control.BindingContext Property (System.Windows.Forms)
Quoted from A problem with using DataGridView control in an MFC CDialog
|
|
|
|
|
I must have missed something. The .Net assemtly winform thing (I'm new to all this .net stuff, so bear with me) loads up fine, but it's just black. The background of the control is usually black, so it's like the rest of it isn't drawn. I should also be able to right click on the control it's self and get a menu to configure the control. I've been struggling with this all day and can't figure it out.
|
|
|
|
|
Hello Nish,
I want to ask you the things. I dont have VC++ 2005 but I want to buy it. Before buying I just want to confirm some of the follwoing things.
1. I have a large project written in MFC VC6. Can I do further modification in that project?
2. Can I convert whole MFC base project in to Form base project ?
Thank you
Mahesh
|
|
|
|
|
Hello Mahesh
msonawane wrote: 1. I have a large project written in MFC VC6. Can I do further modification in that project?
Yes, you can convert the project to VC++ 2005 (a wizard pops up automatically) and you can continue modifying it as a pure native project. Depending on how good your code was, the transition may involve varying levels of difficulty. The VC6 compiler was pretty bad, while the 2005 compiler is among the best C++ compilers out there in terms of ISO C++ compliance. So, you may find that some of your old code will have to be rewritten to confirm to the newer/stricter compiler.
msonawane wrote: 2. Can I convert whole MFC base project in to Form base project ?
That will not be easy, as you would manually have to port it to Windows Forms. Also, since WPF is around the corner, you may want to wait till WPF is out, and then port to that instead of to Forms which is just a transient (IMHO) technology.
Regards,
Nish
|
|
|
|