VB.NET, VB6 and C# Interprocess communication via Window Messaging






4.79/5 (17 votes)
May 4, 2004
2 min read

238385

5860
Article outlining methods for communicating between VB6, VB.NET, and C# apps using Window Messaging.
Introduction
There are quite a few articles on inter-process communication for VB6, and quite a few articles for inter-process communication in .NET. But it is an interesting mix using managed and unmanaged environments for inter-process communication. I have finally got it working after some issues with VB6. :-)
Background
My company is currently developing new applications in .NET, but we still have to support our (main company app) legacy VB6 applications. We had started to use COM-interop from VB6 to VB.NET components, but struck some bugs trying to automate applications from each other. Having a look around, I figured that Window Messaging was independent of VB and .NET environments. So then began my search of code samples and explanations of doing this. Some explained VB6 messaging, some explained .NET messaging, but couldn't find any that did both.
Using the code
For an explanation on the VB.NET sub-classing code, refer to this CodeProject article. I have taken the code straight from here and see no point in explaining it again.
VB6: Form interface:
Private Sub Form_Load()
....
'Create custom window and start listening to window messages.
modMessaging.InitWindowMessaging
End Sub
Private Sub Form_Unload(Cancel As Integer)
'Tear down custom message handling and pass
'back to original message handler i.e this form
modMessaging.StopWindowMessaging
End Sub
VB6: Messaging
' Function to create custom window and setup Message Listening
Public Function InitWindowMessaging()
'\\This statement creates the new window
hWindowHandle = CreateWindowEx(0, "STATIC", VB6_WINDOWTITLE_SERVER, _
0, 0, 0, 0, 0, 0, 0, App.hInstance, ByVal 0&)
'\\ This statement sets the message handling to the
'\\ProcessWindowMessages function defined later.
' We also save the address (hOldProc) of
'\\of the previous MessageHandler so we
' can reset on StopWindowMessaging>
hOldProc = SetWindowLongApi(hWindowHandle,_
GWL_WNDPROC, AddressOf ProcessWindowMessages)
WindowMessagingInitialised = True
End Function
'Function to tear down Message Handling
'and return to original Message Handler
Public Function StopWindowMessaging()
'\\This statement sets the Message Handling
'to be set to the address
'\\of the previous MessageHandler which
'we saved before changing it to ours.
Call SetWindowLongApi(hWindowHandle, GWL_WNDPROC, hOldProc)
End Function
'Function to find VB.NET window and attempt to send message
Public Function SendMessageToVBNET()
Dim hwndTarget As Long
Dim MessageId As Long
If WindowMessagingInitialised = False Then
InitWindowMessaging
End If
'Get TargetWindow handle from global Window Name
hwndTarget = VBNET_WindowHandle
'Get MessageId from API call to RegisterMessage
MessageId = VB6_TO_DOTNET_MessageId
'If Window target exists, then PostMessage to target
If
hwndTarget <> 0 Then
Call PostMessage(hwndTarget, MessageId, 0, 0)
End If
End Function
Function to process messages. If not one of our custom messages,
'then fall through to original Message Handler
Private Function ProcessWindowMessages(ByVal hwnd As Long, _
ByVal wMsg As Long, _
ByVal wParam As Long, _
ByVal lParam As Integer) As Long
If wMsg = DOTNET_TO_VB6_MessageId Then
'\\Respond to the custom message here
MsgBox "window message received from DOTNET environment"
Else
'\\Pass the message to the previous
'window procedure to handle it
ProcessWindowMessages = CallWindowProc(hOldProc, _
hwnd, wMsg, wParam, lParam)
End If
End Function
Points of Interest
One thing which I think is quite nice about this implementation is that it creates its own windows with user defined names. So you have global constants defined in VB6 and VB.NET for the window names. You can then rename your application, and the communication won't break.
The RegisterWindowMessage
API call provides a system-wide MessageId
. Subsequent calls to RegisterWindowMessage
will return the same MessageId
.
VB6: One thing to note that is vitally important is that you need to disconnect your custom Message Handler before the application closes, otherwise it starts to handle messages in the VB IDE. It was quite hard to track this problem down because it would work nicely when I ran the executable, but once inside the IDE, it would crash VB. Once I started writing debug.print
statements in my Message Handler function, all became clear. Somehow, I was not handing message handling responsibilities to the MainForm
.
VB.NET: Nothing much to note here. So much easier in .NET than VB. :-)
Links used while developing:
- Really nice CodeProject article about sub-classing in .NET
- VB6 IPC
- VB6 Window Messaging Tutorial
- The final clue in VB sub-classing
Version 3 now has VB6App2 source code. You can now use Window Messaging:
- VB6 -> VB.NET
- VB6 -> C#
- VB6 -> VB6App2
- VB6App2 -> VB6
- VB.NET -> VB6
- VB.NET -> C#
- C# -> VB6
- C# -> VB.NET
History
- Initial release to The Code Project
- Updated source and demos to include C# project.
- Updated source and demos to include VB6 to VB6App2.