I've spent quite a bit of the last month converting an MFC app to .NET/Windows Forms. Didn't actually convert any CDialog's so I can't comment specifically on that, but found a few general issues.
Because the app concerned had some pretty complex processing in it and I didn't want to spend loads of time debugging I took the approach of converting it a little bit at a time - trying at each stage to make sure that I just did a few small changes after which it still worked - I reckoned doing it that way would save time overall even though it was tedious. I also wanted to completely remove the dependency on MFC, though I wasn't too worried about having __nogc classes in places that weren't using any .NET features. My process looked a bit like this: 1. Switch the compile flags to /clr without changing any code. Make sure it runs OK. 2. Because the main CDocument/CView classes were the main ones I wanted to be replaced by a Form, I gradually removed all the non-wizard supplied stuff from those classes and shifted it into a new __gc class, with all the functions in my CDocument/CView -derived classes simply calling up the equivalent functions in the my new class. Because I wanted to write the new Windows Forms class in C#, I also shifted all my other classes to a separate library project, but if you want to keep everything in C++, you won't need to do that. Once I'd done all that it was relatively trivial to simply remove the CDocument/CView classes and replace with a Windows Forms project. I'd imagine the same approach ought to work quite well with a CDialog. 3. I then carried on converting various classes to __gc ones. Doing it this way, the main issues are the numerous restrictions on how __gc and __nogc classes can interact. You'll find out most of those through getting compilation errors when you stick __gc in front of a class definition- though in most cases getting rid of the compile errors is simply a case of figuring out the correct syntax. Unfortunately the documentation is a bit sparse in this area (and if you look through the archives you'll find several specific queries concerning that area that I've raised in the past few weeks, along with the answers). Main ones are that arrays obviously work differently for __gc classes, you can't return a __nogc object from a method in a __gc one, and __nogc classes can't contain members that point to __gc ones. You'll need to use the gcroot<> template to wrap them. Eg. instead of writing MyManagedClass *pPtr; write gcroot<MyManagedClass*> pPtr; but then you can treat pPtr as if it really was a straight pointer. If you want to start using String instead of CString, and end up using both data types during the conversion period, then you'll find you can convert from CString to String using a direct cast. Going the other way is harder and you'll need to write some custom code using the System::Runtime::InteropServices::Marshal::StringToHGlobalUni() and similar methods. Again you'll find a discussion of that problem and sample code in the archives of this list. One other point - do make sure there is a good reason to convert to managed code (personally I think long term maintainability is quite a good reason if you intend developing the app a lot further in future). If your MFC app is working fine at the moment then you could be giving yourself a lot of work for nothing. Hope that's of some help Simon --------------------------------------------------------------- Simon Robinson http://www.SimonRobinson.com --------------------------------------------------------------- ----- Original Message ----- From: "Ed Fisher" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 24, 2002 7:08 PM Subject: [DOTNET] Mixing MFC App and .NET Forms Hello, I'm overhauling an MFC app. Mainly it consists of redesigning the dialogs. What are the issues I regarding using MFC CDialog versus implmenting them using forms. At some point we want to get to 100% managed code but of course there is a time squeeze. Any inputs would be appreciated. Regards, Ed Fisher You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
