Introduction

Technology keeps leaping forward at a fast pace; applications in projects, large or small, normally cannot keep up with this speed. On one hand, it doesn't make sense to port old code to the new state merely for the status; on the other hand, it also isn't efficient not to use the modern technologies for new designs. Hence, what we get is a mixture of 'old' and 'new' stuff, or as Microsoft depicts it: the Managed and Unmanaged world, creating a new problem when both worlds have to communicate.

There exists, of course, the well-known Inter Process Communication -IPC-, the Microsoft Windows operating system mechanism for facilitating communication and data sharing between applications. This, however, is mainly a property of the old world; the .NET framework does not support such a thing, up till version 2.0. Even then, it is still a question whether it is usable for communication with the old world, or that it is only meant for inter-.NET-communication.

The solution presented here solves this cross-platform problem in a fairly easy and, most of all, simple way, using straightforward methods. Once this path is established, we can also do, for example, .NET Remoting between different machines where one of them is running a legacy MFC application as the object to be communicated with.

Background

Many articles have been written around this IPC topic; the one written by Venkat Raman, called "IPCWorkshop" is quite instructive with respect to the availability of the various communication methods, like MailSlots, NamedPipes, Sockets etc.

Using the code

As said above, the used scheme is very straightforward and easy to understand. The solution consists of two projects: "IPCinCSharp" containing the overridden System.Control.WndProc method, and "SendPostMessageInCSharp" which emulates a VC6-MFC application, firing up the PostMessage event. This emulation is done for simplicity of this article source and demo downloads - it is, of course, possible to use a real VC6 application for this part.

IPCinCSharp

This project does the 'listening to the Operating System messages'; it dispatches the incoming messages identified in the message structure. A threesome switchcase is used for the experiment. The WM_MOUSEWHEEL operating system message is handled in this example to know when the user rolled the wheel within the application window area. The WM_APP+number case shows the actual managed-unmanaged base communication stuff: receiving and extracting the WParam and LParam arguments of the Win32-PostMessage function as sent by the "SendPostMessageInCSharp" application.

SendPostMessageInCSharp

This part of the code does the emulation of the VC6-MFC application, doing a PostMessage event after finding the target window. Due to the emulation, there are some (irrelevant) part of code in it, like the P/Invoke DllImport, responsible for calling the Win32 API function of PostMessage.

History

August 2006 - This is my first CodeProject submission - please be kind.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

The solution presented above is one of many. In general communication isn't that trivial - especially if you want it to be bidirectional (there are companies making good money selling that kind of products).
The Send/PostMessage thing is an old, common usage and used in this example due to its simplicity. The W-and LPARAM types can hold pointers, but .... to what extent? Actually they are meant to pass 'extra' information accompanying the (many-) Windows 'WM_xxx' messages. For example, the WM_LBUTTON, left button down message can have the X,Y coordinate values in the Upper and Lower word part of lParam whilst wParam can hold the information on whether Ctrl/Alt or Shift is being depressed, in other words: direct information.
If you transfer your struct pointer to the 'other side', well then it can read it but it'll be unable to reach the real content of the object (your struct/string) due to app boundaries (indirect information).
If you seek to do this (exchanging objects information) then perhaps .NETRemoting, combined with Send/PostMessage can be a solution for you. (Framework version 2.0 even included IPC!)
As a matter of fact, there is a nice two-way Remoting example on CodeProject: (mind you, Remoting is not bidirectional, by definition)
http://www.codeproject.com/csharp/TwoWayRemoting.asp, authored by Marcel Heeremans.