Develop Reference

Integrating WPF application with WinForm application

I have an winForms application fully written in VB.NET. I have to start importing this application into WPF written C#. For the starting, I want to do this only for one module of the application. Is there any way I can pass VB.NET objects to a C# code, call a WPF application from a WinForms application and vice-versa ?
How should I approach this problem? Any help would be appreciated.

There is no easy way to migrate winform applications to Wpf.
You should carefully consider the reasons why would you like to do it and the effort it will take vs the profit.
that being said you can start by hosting your winform by a wpf application using WindowsFormHost then you can start by rewriting your controls one at a time and using ElementHost to host them in the winform.
Since you would like your application to be robust and use MVVM I personally think that it will take too much effort to migrate and it will be more reasonable to rewrite the application using already existing modules(logic not ui modules)
Regarding using Vb.net object in c# it can be done easily because they are both managed languages and are being compiled to CIL:
During compilation of CLI programming languages, the source code is
translated into CIL code rather than platform or processor-specific
object code. CIL is a CPU- and platform-independent instruction set
that can be executed in any environment supporting the Common Language
Infrastructure, such as the .NET runtime on Windows

Yes u can call wpf application in windows and vice-versa.For that u have to configure in .config file
In Through ElementHost u can access the controls

How to embed a win32 Delphi Form in a .NET Winform

We would like to open some Delphi (win32) forms from .NET and embed the Delphi Form in a .NET MDI-form.
If we just call the exported method in our Delphi DLL it is no problem to embed the form, however then we have problems with shortcuts and keyboard events in general. We believe that it’s because of incompatible messageloops.
We’ve then tried to execute an Application.Run in the exported procedures in our Delphi DLL’s on a separate .NET-thread and it works the first time, but fails when we try to open the form more than once.
Does anyone know how to interop the way we would like to do it: embed a win32 Delphi Form in a .NET Winform?
#All: First of all, thanks for your responses
We found a solution to our problem: We moved the Delphi Application.Run into the exported procedure that starts the windows.

If you have the source, you could try porting it to Delphi Prism, which generates .NET code. Although, if you're using the VCL, you're fighting an uphill battle. Whereas Delphi 2006 had a .NET implementation of the VCL, Prism is just Object Pascal for .NET with no VCL adapter.
Another tool that is available is Hydra I haven't used it personally, but they claim to provide interop between .NET and "legacy" Delphi. If it works as they claim it does, it might be your best bet for transitioning your old Delphi code to a .NET application.

I would probably run the Delphi application in a separate process, set the parent window for the Delphi windows to your MDI container (instead of the default: the desktop, referenced by HWND 0), and marshal any necessary data between processes using typical inter-process messaging.
Then again, this is essentially the same as exposing your form as an ActiveX object. I just like to take Google Chrome's approach and isolate windows/tabs into separate processes.

How to create an in-between library?

I am looking for some information on how to achieve something with libraries in C++ and c#.
What I would like to know is how to approach the following problem:
C# application: -has a window
C++ library: -has a function called create_button(x,y), when
invoked, it will create a button on
the c# application's window. (if the
C# application is not running,
nothing will happen)
C++ application: -dynamicaly links to the C++ library and calls the create_button()
function.
How would I approach this problem, I would be glad to hear some of your ideas.
The platform is windows. My question is, how would I let the C++ library communicate to the c# application to create a new button? Is it linked, sockets, ... I'm particulary thinking of GTK+ in linux, you link to the gtk+ library, but how does the library interface with GNOME to create a new window etc, something like that. I'm not interested in writing dlls and linking those to a c# application, I'm interested in creating an in-between library.

I can't think of any sane way to do what you want to do. What I believe you should be doing is creating functions to do the drawing in the C# app and then exposing some messaging interface, such as a socket, that allows external apps to send messages that command the C# app to do what you tell it. When the C# app receives messages of with message type DRAW_BUTTON, it draws the button, with whatever parameters were specified in the message it received.

You're going to run into problems here since C# is managed and C++ is native. As far as I know, the only way of calling native code from managed in the CLI is by using the P/Invoke layer, in which case you would need to import a DLL, write a prototype, etc.
In addition, I believe that the P/Invoke calls are to C functions, and not C++, although you can get past this by adding a C library to call into which in turn calls your C++ library.

If you can create a small but proper HWND in C# (don't know the widget), you can use that and create a c++ window using the C#'s window as parent.
We did exactly this a few years ago for a java/c++ process pair. However, the Java app could report the HWND value to the c++ app over RPC, so it wasn't that hard to setup.

Given that you control the code of the C# application and you control the code of the C++ application and, presumably, the 'in between library'. I find myself asking "why are you doing it like this?"
If you want the C++ app to be able to cause the addition of a given button on the C# app and for the press of that button to be able to communicate with the C++ app then, personally, I'd use standard IPC and have a communications channel between the C++ app and the C# app and simply have the C++ app ask the C# app, via IPC, to display the button and then have the C# app send whatever detail (most probably the fact that the button was pressed) to the C++ app via the same IPC channel.
If this route wont work then I think you need to clarify the problem that you're trying to solve as at present I think your current 'solution' is on the wrong track and so an answer telling you how to achieve your current 'solution' would be misguided.

Embed non-managed directX into C# form

I got a quick question about running a directX application (C++) in a managed environment. I'm attempting to write a MDI tool (in C#) where the background of the parent window would be an embedded render window of directX (C++).
I've read ways that involved writing the C++ into a native dll, however it would be prefered to be able to have the C++ projects included within the solution (I dont even know if that's possible though). Eitherway, if you know of some helpful steps, hints, or if this is a bad idea in general, please let me know. Thanks!

The easiest way to do this would be to add a C++/CLI project to your solution. This would then enable you to use the DirectX COM interfaces directly and create a managed wrapper that's easy to call from your C# code. I've taken this approach a few times and it's by far the easiest way of mixing DirectX and .Net that I've ever tried. Managed DirectX used to be an option, but it's no longer supported and it was a fairly small subset of the full COM API anyway.

First of all writing the C++ part in a different dll file doesn't mean that it couldn't be at the same solution as the C# project.
In order to use native DX to render on a managed window you need to pass the HWND window id (use form.WindowId.ToInt32) to the C++ D3Ddevice c'tor. after that each time you'll render using that device it would render on the .NET window.
To do this you probably need two saparate projects - a C++ dll & .NET project. use COM wrapper or p-invoke to pass the HWND to the C++ dll.

If you don't want to spend too much time on writing C++ code for DirectX, you can consider using
SlimDX, since Managed DirectX 1.0 is out of the question, where as 2.0 never leaves the beta and later replace with XNA which has quite different from DirectX itself, and require you to install XNA Game Studio
SlimDX is the opensource version of managed directx with slightly different API and internal structure, but it's easy to use. The recently released version is very stable. I'm currently using it to write a production application.
SlimDX
Managed DirectX

C# controls in a MFC Application

I am responsible for the User Interface of an application written completely in Visual C++ using MFC and some third-part controls. I would like to use C# (WinForms or even better WPF) to improve the application look&feel.
I would like some advices about how to do it. Links, articles, examples...
Right now the user interface is isolated in a single project and I don't want to compile the whole module with CLR. So how do I have to manage that from the architectural point of view?
I have already looked at the Internet for the subject and read MSDN information. I would like more detailed information...is it convinient? pros/cons? have you used this approach successfully in a "big" application?
I don't want to compile the whole ui project with CLR...can I just have all the .NET code in a isolated project and call it from the ui project? what's the best way to do it?
Thanks in advance.

A good starting point is the Win32 and WPF interop page on MSDN.

I found this codeproject article gave a good introduction to the subject of mixing mfc / winforms code.

When faced with the same problem, I made an ActiveX control in C# and used it in my MFC app. The folks at MS took out support for building ActiveX controls with .NET, but it's still possible to do so with a plain Jane COM class which has a custom [ComRegisterFunction()] and [ComUnregisterFunction].
Although MS would like to tell us that the /clr flag will solve our problems, it measurably slowed down my large MFC app.