views:

380

answers:

5

Some classic Windows/C++ applications can't easily be moved to managed C++.net, due to use of external libraries. Is it feasible to use newer GUI libraries like winforms (or even WPF) with such applications, 'dropping in' new controls to replace stale-looking MFC?

Or is it not really worth it, and would take a lot of time?

+1  A: 

A better approach would be to create a new .NET project (C# is your friend) for your UI, and reference your C++ DLLS from there. You're not going to have an easy time mixing managed and unmanaged code in a single project.

See How do I call unmanaged C/C++ code from a C# ASP.NET webpage. It talks about a web page specifically, but the code is identical for a winForms or WPF app.

David Lively
I disagree. I've found it easier to use mix managed and unmanaged code than to create a separate project. By using C++/CLI to write your managed code, you can access unmanaged data very easily. Much more easily than P/Invoke or COM as mentioned on the question you referenced. But this may be a matter of personal taste.
Ray Burns
+3  A: 

I've found that C++/CLI is very capable. Are you actually running into problems? It should be able to compile your MFC project directly.

But mixing WinForms and MFC within the same thread could be difficult as they both want to run their own message loop. As Ray Burns has suggested, WPF may be more cooperative with MFC.

Frank Krueger
Yes. However the message loop is not a problem if you are using WPF instead of WinForms. This is because unlike WinForms, WPF does not depend on the message loop for anything but instead uses WndProc for everything. All the details are taken care of for you in WPF's HwndSource class, which is used to integrate with unmanaged windows and also for creating top-level WPF windows.
Ray Burns
There is no issue with hosting Windows Forms controls directly in MFC windows. The WinForms controls are wrappers on native windows after all, they participate in the overall messaging process quite seamlessly.
Aidan Ryan
A: 

It's not really worth it, and it would take a huge amount of time.

It's possible to have unmanaged C++ code host the CLR, and to have the managed code run the UI.

But, it's definitely not a trivial task.

An easier approach would be to rewrite the unmanaged code a bit to be invokable via P/Invoke or COM interop, and have a managed app (with winforms) call the unmanaged code.

Eric Brown
Ray Burns
But that's not unmanaged code; C++/CLR compiles to IL, not X86/X64. Since the questioner has a bunch of external libraries, he needs something that actually calls native code. External libraries are typically binary-only, so recompiling them isn't an option.
Eric Brown
+2  A: 

Because of IJW it's quite easy to use WinForms or WPF from unmanaged code. More lilkely, though, you'll want to write the new components in managed code and just embed them in your unmanaged application. That means that for all the new stuff you won't have to deal with memory management, etc.

WPF is much more powerful and nicer to use than WinForms, so I would definitely bypass WinForms if you haven't been using it already.

One consideration is you'll want to take advantage of the data binding power of WPF. To do this you'll need to expose your unmanaged data as COM classes or copy the data into managed code. An easy way to do this is to write managed wrapper classes in C++ that access the unmanaged data. Another easy way is to directly access the business object layer (or database) from managed code. It depends on exactly what your current data layer looks like.

Ray Burns
A: 

See my answer to a similar question.

You have plenty of options for hosting managed UI in MFC.

Aidan Ryan