In Visual Basic it is possible to obtain one or more additional separate code threads to operate a single program. The threads are stable and secure and communication between them is provided for intrinsicly. There is no need to hack the language with unpredictable API's.

This page focuses on how that is done and demonstrates the problem you may have (or not be aware of) in starting these threads running.

Client and server are object oriented programming (OOP) terms. To simplify matters in the ensuing discussion, the client will be a standard EXE. The server will be an ActiveX component object instantiated by the client. The client sends information and requests to the server object. The server responds when the job is done by raising an event in the client and usually returning some processed information to the client.

A thread is a list of assembly level instructions that the CPU (central processing unit) of your computer executes one after another, one at a time, all the way until a program ends and releases the thread. The Windows?programs that you can switch between when you click on the taskbar at the bottom of the screen are operating on separate threads. The amazing thing is that not only can you switch from one program to another, but they can all run at once!

This is possible because the CPU can switch code threads. It stops executing one thread, saves all the information about that thread, loads all the information about the next thread in line, and then starts executing that set of instructions. Countless thread code switches are happening right now in your computer every second as you read this.

So technically the programs on your taskbar are not all running at once, but the switching normally happens so fast that it seems like they are.

A switch oclearcase/" target="_blank" >ccurs whenever the CPU gets a break from the program holding the presently executing thread. In Visual Basic these breaks are provided automatically when waiting for some type of input (a key press or a mouse click). If your code performs many instructions without a break, it may monopolize the CPU so that other programs can't get their share of CPU time. In such a case, it is up to you as a good programmer to be courteous and judiciously allow breaks with the DoEvents statement.

If you play music on your computer while you type an email reply, or if you keep more than one web browser window open at the same time to download one page while you read another, then you are aware of the benefits of separate code threads.

In these instances, the operating system provides separate threads automatically, and the applications really don't have to work together as client and server.

Of course such a discussion would be moot if there were no vehicle for implementation. Fortunately, Visual Basic has provided us such a tool through ActiveX, and specifically the ActiveX EXE type component. It is there specifically to give us a separate thread - if you only need a same thread library, then choose an ActiveX DLL as your project.

ActiveX has been designed by Microsoft to nudge Visual Basic programmers toward object oriented programming. It is through the instantiation of a required public class that ActiveX is able to pipe us into the safe haven of the COM standard and provide us with secure conversations between separate threads. You will also be happy to learn that the App Object has a .ThreadID property which will be your compass for exploration.

It is the ActiveX EXE we shall explore for the separate code thread it provides. Visual Basic has the ability to allow for multi-threads of separately threaded EXE servers (additional threads for each instantiation) through unattended execution compilation options. The examples herein only deal with single, separate threads of execution.

Being a single, separate thread does not mean that it can not have more than one client instantiating and calling it. When a component has one thread of execution, code for only one object executes at a time. The Automation feature of the Component Object Model (COM) deals with this situation by serializing requests. That is, the requests are queued and processed one at a time until all have been completed. It is limited because if control is yielded, the next queued call is allowed entry and if unanticipated, reentrancy problems may occur.

Simply calling a public method of a server running on a separate thread will start the server executing code. The problem is that the calling client will wait at that instruction for the return from the server. This will happen even if the call is to a Sub in the server (i.e. expecting no return value as with a function).

To illustrate:

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

Public Sub waitAwhile()
    Dim j#, k#
    For j = 1 To 300000
        k = j
        DoEvents
    Next
    
    RaiseEvent done(App.ThreadID)
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.waitAwhile
    Print "Client done at: " & Str$(Timer) & _
        "   on thread: " & Str$(App.ThreadID)
End Sub

Private Sub ts1_Done(id&)
    Print "Server done at: " & Str$(Timer) & _
        "   on thread: " & Str$(id)
End Sub

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

The output proves two things: There are, in fact, separate threads The client waits until the server is finished.	The Output:

The hoped for benefit of separate threads is that execution would proceed for both threads. If one thread has to mark time waiting for the other to finish, then there is little benefit from separate threads.

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

The output demonstrates execution of both threads.

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.