How do you call MFC C++ Dialog legacy code from a C# form?

[bd]

Here is my question...
Can anyone refer me to a white paper or sample code that describes how to
use modal and modeless MFC dialogs from a C# application? Or, can someone
provide some hints based on their experiences?

Here are some details...
My company has a rather large program written in Visual C++ 6.0 using MFC.
We want to add new capabilities to it and migrate to VisualStudio.NET. Since
we developed and own the source code, we have some flexibility. We can port
or recreate the Visual Studio projects, recompile and make minor changes to
the C++ source code. But, we cannot throw away the old code and start over.

The program uses an MDI interface. It has several DLL's with many modal and
modeless dialogs (derived from CDialog, CPropertyPage, CMDIChildWnd, etc.).
It also has many custom edit controls (derived from CEdit). In particular, I
am most concerned about who owns the Windows Message Pump and how it is
controlled/shared. Gradually, we would like to port each business object to
C# or VB.NET, providing both an MDI "desktop" and a Web Form interface with
each object.

In order to formulate a migration strategy, I have made several attempts to
get a simple prototype working that creates a modeless MFC dialog from an
MDI C# form:
1) Use DLLImport and call a static function, passing in
"this.ActiveControl.Parent.Handle". I derive from IMessageFilter to share
the message pump. But, using static functions, I loose instance data with
two child windows of the same type.

2) Use DLLImport again, plus pass in a "void pointer" that is cast to
"MyDialog" derived from CDialog in the DLL. But, the memory seems to go out
of scope. I am not using "fixed (type*ptr = espression)" because it seems
like it is only intended to be used briefly.

3) Port the MFC classes to "Managed C++". But, I get compiler messages
something like "managed class cannot derive from non-managed class
(CDialog)".

I have not tried these yet:
1) Wrap the MFC code in a COM object.
2) Create a user interface thread with its own message pump then somehow
wrap the C++ code in the thread object.
3) Create a user control (wrapping the MFC code) on an MDI child form.

Any thoughts?
Thanks,
Bill.

[NETMaster]

I'm afraid you will have no easy way to close the huge gap between .NET and MFC.

>> Port to "Managed C++", but get compiler messages something like "managed class cannot derive..
with MEC++, I guess you have to 'WRAP' (not derive from) MFC classes?
[but I don't think this will work at all]

You may also try to first build a 'regular DLL' from your existing MFC src:
http://msdn.microsoft.com/library/en-us/vcmfc98/html/_mfcnotes_tn011.asp
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q140850

"bd" <a> wrote in message news:#g0W0EljBHA.2344@tkmsftngp07...

> Here is my question...
> Can anyone refer me to a white paper or sample code that describes how to
> use modal and modeless MFC dialogs from a C# application? Or, can someone
> provide some hints based on their experiences?

> In order to formulate a migration strategy, I have made several attempts to
> get a simple prototype working that creates a modeless MFC dialog from an
> MDI C# form:

[Edward Diener]

Create a DLL with a single exported function which will bring up your
MFC dialog, and package your MFC dialog in that DLL.
The function should probably take just a single HWND parent window as a
parameter. You can then call that exported function from C# passing
an HWND for the parent form.

[Nicholas Paldino [.NET MVP]]

Bill,

You are not able to access MFC classes through
C#/.NET. Your best bet would probably be to create
managed wrappers for your classes that are exposed to
the .NET framework. This is very tedious, but it will
preserve your code completely, as well as allow for future
development to take place in C#.

If you can wrap your classes in a COM+ component,
then that would be acceptable as well, since you would be
able to use COM interop to access your classes.

Also, you could use the P/Invoke way of accessing
functions in DLL's, but you can only access functions that
are exported, not classes, so you would need something to
represent an instance, perhaps a handle passed back and
forth.

To me, it looks like your best bet (although one of
the more tedious routes) is to create the managed wrappers
for your existing classes.

Hope this helps.

- Nicholas Paldino [.NET MVP]
- casp...@caspershouse.com

>.
>