MThreadVB - The Generic Multithreader For VB

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)