Generic reminder:
This Demo requires the RichClient3-Toolset,
which you can donwload here:
www.datenhaus.de/Downloads/dhRichClient3.zip
Please follow the Readme included in the Zip above,
to setup your Dev-Machine appropriately, 
before you run the projects from this Demo.


This Folder contains threading-demos,
which make use of the new (more high-level)
threading-support in dhRichClient3.dll.

In short:
The approach always needs to create not
only 'a thread', but a Thread-Object *on*
a thread - and is basically comparable to
what you already know and expect from
the "usual, easy to use AX-Exe-Threads" -
but without the need for an AX-Exe of course.
These ThreadObjects (or better: ThreadClasses)
can be "programmed" without the need for
"special Helper-Objects" and also normal
VB-Events are allowed and supported within
these ThreadClasses.

So you will usually start with the definition
of such a ThreadObject first (in a Class-Module).
Good, when you test this Class and its Methods
before you make it a "Thread-Class", so you
would not have to "fiddle around" with thread-
debugging that much, which is always a bit more 
difficult than "normal Debugging" (usually  
involving Log-Writes etc.).

Ok... once you have this Class with "proven Methods",
you can put the Class into a VB-AX-Dll-Project
and make it a Public-Class there (set its 'Instancing'
property to 5=MultiUse, which is BTW the default
for new created Classes in an AX-DLL-Project).

Then compile this AX-Dll-Project (make it a binary,
since the "cientside usage" from within your
Main-Thread (in your calling Exe) will create,
or better instanciate - the Threadobject only 
from an already existing Dll-Binary - but this 
"instanciation on a separate Thread" is always
done regfree, so you will never have to register
such a "Thread-Dll" on a customer-machine.

The calling MainThread (usually your VB-Std-Exe),
(I will call it "the clientside" from now on) does
not need a project-reference to your ThreadLibrary
(your ThreadClass) and vice versa - that's nice -
and different from AX-Exe-Threading, so on the
clientside we will always work "LateBound" against
such a Thread (ThreadObject), when "talking" to it
(passing parameters, calling methods either async.
or synced - both variants are supported - and also
the Events, raised from your Threadobject are received
"LateBound", but all that becomes more clear, when
you look at the concrete examples and the comments
in these Demo-Projects.


I have put 4 Client-Projects together, which can 
be grouped into a:  simpler Threading-approach
(so please start with that first) and an "advanced
Threading-approach" (you can differentiate these
projects over their appropriate *.vbp-Names, which
either contain the string-part 'simple' or 'advanced'.

E.g. the simple approach consists of:
ThreadSimple.vbp (ThreadCreator-project, acting as "host")
and...
ThreadSimpleClient.vbp (ThreadConnector-project, requiring
ThreadSimple.vbp to run)

The intention behind that is, to demonstrate that
the threads can be used either InProcess (that's
what ThreadSimple.vbp demonstrates as a normal
ThreadCreator and therefore being also the "Thread-
Host") - but it is also possible, to get access
to an already running (hosted) ThreadObject from
a different *process* - and that's what is demonstrated
with ThreadSimpleClient.vbp (and also with the appropriate
ThreadAdvancedClient.vbp, which requires a running
ThreadAdvanced.vbp then).


All these 4 client-threadprojects work against the
same ThreadLib.dll (the fifth project), which contains 
two different Thread-WorkerClasses, to "serve" the clients
appropriately (cThreadSimple and cThreadAdvanced).
This ThreadDll-project is included as:
ThreadLib.vbp
inside the SubFolder 'Threadlib' - and it compiles
its Dll (Threadlib.dll) per default back-into-the-
App.Path of the 4 Client-Projects.

Ok, that much to a small Documentation-attempt, 
before you enter the Demo-Projects and start
reading more concrete comments there... ;-)

Maybe some additional comments about the used
APIs behind all that:
The approach is using named-pipes (in message-
mode) under the hood, combined with a Variant-
parameter-serializing, which accepts all normal
VB-Types including their Arrays - and it also
supports Object-Parameters and -ReturnValues
as long as these Objects are "COM-serializable",
which is given for example for ADO-Recordsets,
VBs StdPicture-Objects - and also for the
SQLite-Recordsets and the cCollection-Class
of dhRichClient3.dll. 
So the approach is basically similar to what
you can do also "cross-machine" with the RPC-
classes of the RichClient, but due to its usage
of Pipes it works ca. 3 times as fast as the
socketbased RPC-classes - a single client can
reach ca. 10000 Calls (or Requests) per second,
which shows, that the performance is basically
"on par" with the OLE-Marshaling, which is used
under the hood when you use and talk for example 
with (OutOfProcess) AX-Exes.


Olaf Schmidt

