[ADVANCED] Multi-threaded VB6

[Schmidt]

I was running Ax-EXE threading. How do I know if I am multi-process-mode?

If you create AX-Exe-Class-instances via the New Keyword (e.g. from a Std-Exe) -
then those (Thread-)Class-Instances run "Out-Of-Process" (of your Std-Exe).

The approach you linked to in your first post - is InProcess-AxExe-Threading,
because the Demo is running "from inside an AX-Exe in GUI-Mode" +
it starts new Ax-Exe-Class-Instances internally via CreateObject(AxExe.ProgId)

The Demo is a bit "clumsy" though - especially the FindWindow-fiddling in Sub Main
is completely unnecessary, because a simple test like below is enough:

Sub Main()
  If App.TaskVisible Then fMain.Show 'follow-up Sub Main-entries will have App.TaskVisible = False
End Sub

Why does the data module need its own thread?

First let's make it more clear, what "DataModule" we're talking about.

The little Demo in my prior posting is not "Shared-DataClass-based"
(but relies on SafeArray-Ptr-Passing from a normal VB-Array-allocation which was generated in the Main-Thread).
So this is the faster shared-data-approach, which avoids COM-marshalling (since it is not "AxExe-DataClass-based") -
but you will need to protect your Shared Array-Data "by hand" (via Critical Sections) - so the speed-advantage comes at a cost.

The other approach which was mentioned is the easier one - because concurrent access is "fully managed" under the covers.
This is the "AxExe-DataClass-based" approach, where COM handles the access for you.
And the Singleton-like DataClass-instance should neither be instantiated on the Main-Thread (the GUI-thread) -
nor should it be instantiated on one of the Worker-threads - because any of these threads might "enter a longer processing-routine"
(and whilst being "in that routine" the DataClass-instance on such a thread would not be reachable from other threads).
Note that I wrote instantiated on in the last paragraph - which is different from "passed into" or also "used within" (a thread).

Ok - long story short - the Singleton-AxExe-DataClass should be instantiated on its own thread (via CreateObject),
to guarantee a thread which will never "enter any longer processing-routines" (because this Class does not contain any processing-routines).

If the two threads have access to the same memory locations, cant they just use them without blocking/deadlocking?

As said - in case of:
- the SafeArray-Ptr-Passing-approach, there is no blocking (other than your own CriticalSection-handling)
- in case of the Singleton-AxExe-DataClass-instance, there will also be no blocking (when it runs on its own STA)

Here is an example for the latter (simpler) approach in an "InProcess-AxExe-Project":
AxExeInProcessThreads.zip

HTH

Olaf