If the client could raise an event in our server in the first place, instead of making a call, our problem would be solved. No waiting occurs when you raise an event.

Unfortunately, Visual Basic has provided for events that go only in one direction - from the server to the client (commonly to notify the client that the job is done). Apparently Microsoft''''s assumption is that if a client wants to contact the server then it should make a call.

Note that we could force the client to budge with an event from the server, but that method is bound for reentrancy trouble. The technique also requires double communication through the COM barrier, which is not a strategy for optimal performance.

Reentrancy occurs when a thread of code is interrupted by an event such that the thread reenters itself at a different point in the program. Hopefully the code executed is a little snipit of your program that can be executed without adversely effecting the thread that was interrupted. If an interrupting thread changes module-level data the first thread was using, the result may be unfortunate.

In the situation described, the client would have one portion of its thread waiting for the return of the server call, another executing code as the result of the server originated event, and finallly a third when the event arrives from the server indicating that the job is done.

Note that the third reason stated above to have a separate thread in the first place is to avoid reentrancy problems.

There are examples and discussion in Books on Line in Help and a rather bewilderingly complete project in VB\samples\CompTool\ActvComp\coffee. You could spend considerable time attempting to decipher the heavily commented code covering a maze of files.

If you study it, at some point you come to realize that the only thing they are doing at any time to demonstrate a separate thread is to enable an API timer. Unless visual demonstration of apartment threading is your goal, it is a colossal waste of effort. Well not quite ...

It becomes apparent that somehow enabling a timer is the key.

A more obvious method for initiating server action would be to simply enable a timer that periodically checks for data (deposited by the client) to act upon. But if you, like I, prefer avoiding the attendant overhead of a continually running timer, I believe you will find the following solution appealing.

To illustrate:

''''==============================================
''''The Server Code: compiled as an ActiveX EXE
''''     Class name: threadServer
''''==============================================
Option Explicit
Event done(id&)

Dim a&, b&
Dim WithEvents f1 As Form1

Private Sub Class_Initialize()
    Set f1 = New Form1
End Sub

Public Sub theCall(ByVal n1&, ByVal n2&)
    a = n1: b = n2
    f1.Timer1.Enabled = True
End Sub

Private Sub f1_TimerNotify()
    processInfo
End Sub

Private Sub processInfo()
    Dim j#, t&
    For j = 1 To 3000000
        t = a + b
    Next
    RaiseEvent done(t)
End Sub

Private Sub Class_Terminate()
    Unload f1
    Set f1 = Nothing
End Sub

''''==============================================
''''The Form with a Timer on it (in the server)
''''==============================================
Option Explicit
Event TimerNotify()

Private Sub Form_Load()
    Me.Timer1.Enabled = False
    Me.Timer1.Interval = 1
End Sub

Private Sub Timer1_Timer()
    Me.Timer1.Enabled = False
    RaiseEvent TimerNotify
End Sub

''''==============================================
''''The Client Code run from the VB IDE
''''==============================================
Option Explicit
Private WithEvents ts1 As threadServer

Private Sub Form_Load()
    AutoRedraw = True
    Set ts1 = New threadServer
End Sub

Private Sub Form_Click()
    Cls
    ts1.theCall 6, 7
    Print "Client done at: " & Str$(Timer) & _
        "   requesting: 6 + 7"
End Sub

Private Sub ts1_Done(ans&)
    Print "Server done at: " & Str$(Timer) & _
        "   answering: " & Str$(ans)
End Sub

Private Sub Form_Unload(Cancel As Integer)
    Set ts1 = Nothing
End Sub

On the same machine, the ultimate execution of separate threads is manifested by sharing the CPU through thread switching. Therefore, this output has not provided us with proof of simulltaneous execution. (It has proven that many instructions can be executed in a millisecond.)

Such output would require additional programming in both client and server objects for synchronization of their tasks (presumably with additional events and/or calls) However the technique of initiating a second thread remains intact and it may be applied without additional synchronization code if your server object is, in fact, instantiated remotely.

For out of process calls (and events raised) a proxy service called marshaling is required to pass parameters. Whatever you pass is always passed "by value" via marshaling. A reference (which may be specified) forces values to also be marshaled back to the caller (also by value).

Therefore pass everything ByVal. Arrays should be made Variants so that they may be passed ByVal. This applies to arrays of any type since none (except Variant) may be passed ByVal in Visual Basic.

''''===============================================
''''Code in the standard EXE client
''''===============================================
Dim dbe As myServerClass
Dim myArray(6) As Variant

Private Sub SendToClass()
    dbe.setClassData myArray()
End Sub

''''===============================================
''''Code in the server class
''''===============================================
Dim wholeClsVis(6) As Variant

Public Sub setClassData(ByVal a As Variant)
    Dim j%

    For j = 0 to 6
        wholeClsVis(j) = a(j)
    Next
End Sub

To demonstrate the techniques advanced on this page in a more robust functioning application, download the Mini-Database Project (26k) and see the complete commented source code.