Multithreading in VB - Where the waters become murky....

Multithreading, as far as VB is concerned, is very difficult to implement. Though VB supports multithreading, it basically supports it only for ActiveX EXEs and to some extent in ActiveX Dlls (The ActiveX Dlls basically allow very primitive multithreading - It just maps instances of itself onto client threads that request its services. If your client is single threaded, the DLL too does not multithread !)

Sometime back I had demonstrated a method of multithreading using ActiveX EXEs. Though it is very stable, the trouble is the code tends to be very cumbersome... So I have designed a new generic multithreader, that, though not as stable as multithreaded ActiveX EXEs, is sufficient for most uses...

A Bit of history....

Soon after I demonstrated how to multithread using ActiveX EXEs, I realized that though the technique was useful, and though most of you appreciated it, it tended to be somewhat cumbersome and then I began to think of ways of creating multiple threads using other methods.... Soon afterwards, I came across an article written by an extremely talented and innovative programmer, Matt Currland (who is unfortunately not a member of PSC), where he demonstrated how to use CreateThread() safely with VB.. But the problem was, the example was very complicated and difficult to understand owing to the many class modules it used and the zigzag nature of execution... After hours or effort, punctuated by crashes, freezes and quite a few reboots, using some inspiration from his article I have created MThreadVB. Though it may not be as "technically right" as his code, I had to sacrifice some of the correctness for ease of use and the generic architecture.... (Which his code sadly did not provide - His was basically a demo program)

Some Technical Stuff ....

How does the multithreader work ?! You might ask - Here's the answer !

Normally, all VB programs are heavily dependent on the runtime DLL for its functioning.In VB 6, within the multithreaded function (Called By the CreateThread() API once the thread has been created) , any calls
to the runtime DLL fails (due to some reason perhaps which only the Microsoft VB team might know !) causing your program to crash immediately....
Even an API call is not really compiled in "real" native code in VB and is interpreted by the runtime DLL...
An API call too thus ultimately involves calling the runtime DLL,that causes VB to crash.

Those of you who do not believe this can do a simple test - Open the API viewer, select the mciExecute API defied in the Win32API.txt file... Place it in a project and compile it.... Even though this API is a part of WinMM.Dll, you will find no reference to the WinMM.Dll in case you view the executable in the Depencency Viewer (since the code referencing the DLL is not placed "explicitly" in the executable. When you call the API, the actual call to WinMM.Dll is ultimately made by the runtime DLL only) .... But if you were to open the EXE in MS-DOS editor, you can see the text strings "winmm.dll" and "mciExecute" !

Most standard VB statements and functions such as Set = , For...Next etc also call the runtime DLL and ultimately even these fail... (So much for native 'code compilation !)

If an object could be created within the multithreaded procedure, the VB runtime starts behaving properly...
The trouble is,the standard VB instantiator functions fail within the multithreaded procedures...
Therefore, I have used the ThreadAPI.Tlb type library to bypass the Runtime and directly call the OLE/COM 
APIs (This can be verified using the Dependency Viewer) and create a dummy object inside the multithreaded
procedure (using the CoCreateInstance API). After this has been done, the runtime DLL starts 'behaving properly and it is possible to ' call all VB functions safely...

Some features and the Do's and Dont's -

1>The multithreader is completely event based, that is the multithreader notifies the client app of any event such as threads terminating, or the a priority change...

2>For creating all a programmer has to to is the call the CreateWin32Thread() Function, and relax ! So no need to fiddle around any more with ActiveX EXEs !

3>To perform File I/O and to show forms from within threads (which were earlier not supported) do the following -

    Sub MThreadProc(DummyArgument as Variant)   'Your multithreaded procedure
        'Some code....
        pThread.ObjectInThreadContext.SomeSubroutine   
    End Sub

    'In the above code SomeSubroutine is a Sub or can be a function defined in the same form or object in which the Sub MThreadProc is defined (pThread is a reference to the DLL)

    Sub SomeSubRoutine       
        'Your file I/O code or code for creating and displaying forms (Form1.Show etc) goes here 
   End Sub

Special Note: In the above statements, the ObjectInThreadContext property returns a reference to the object containing the multithreaded procedure in context to the new thread 

4>Always call the END statement when you want to end your app

I must thank Robin Lobel for reporting the form show bug(it was never noticed by me) also Willian Tarlton who induced be to think until I got a solution, after he reported his extreme need for file i/o within multithreaded procedures

5>As far as posible do not use the MThreadVB component within the IDE - Use it only with compiled EXEs

Please mail me at srideepprasad@digitalme.com if you find bugs or have any suggestions

New ! This article has been updated to include a new class called ThreadLaunchEX that allows multiple thread creation in real time. Though it has not been explained, I must say that it can be used just as the Thread class (used in the Demo) - Only you must identify all threads with a unique threadId parameter. This is not necessary if you are only using the simpler Thread class !

Please vote if you find the code useful... Thank You !

A strange "Dissappearance" and a vote of Thanks !
I must first of all thank all my fellow programmers and developers at PSC for their tremendous response to this code... 

However, recently, this piece of code (along with almost 500 others) was deleted due to site hacking. Therefore, I am resubmitting it.. The good news is that Ian, one of the people behind PSC is sincerely pursuing this matter to bring the hacker to justice...!

(For more information on the hacker attack please visit - (http://www.pscode.com/vb/scripts/ShowCode.asp?txtCodeId=35215&lngWId=1)