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

• Download demo code - 25 Kb
• Download source code - 25.1 Kb

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

1. Initial release to The Code Project
2. Updated source and demos to include C# project.
3. Updated source and demos to include VB6 to VB6App2.