MultiThreading in VB6

[Schmidt]

Sorry I was incorrect, I tried a different example to convert my project from standard.exe to activeX.exe.
I have Just tried your approach, and I did get it to work.
Can you confirm the way I Understand it.

Once I have my activeX exe. I can now create a class withEvents, make it public creatable, then call it to get my stats from the bass.dll library.

- Yes, you can declare a ClassType-Variable WithEvents (for your Main-Thread or "GUI-Thread", usually in one of your "consuming Forms")
- The Class(Type) of that variable can be defined in an appropriate Class-Module in the same AX-Exe-Project
- The above "ThreadClass" can then be instantiated later (on its own thread), when its 'Instancing-Property' is at "5 - MultiUse"
- In case the instantiation of this Class is performed per VB 'New' Operator, the Class is *not* instantiated on its own thread, but on the calling thread instead (usually this is the Main-Thread)
- In case one is using the correct ProgID in conjunction with: CreateObject("MyAppName.cMyThreadClass"), then the same Class *would* be created on its own thread (this applies to the compiled executable, in the IDE no separate Thread is forked)
- The ActiveX-Exe Project-Settings have to be [Thread per Object] or alternatively a ThreadPoolCount > 1 has to be set, to spread the created "ThreadClass-Instances" evenly across the available Threads in the Pool

As explained in the Thread here: http://www.vbforums.com/showthread.p...ted-Threading)
- Synchronizing "threaded activites" is usually not a problem with COM-threading, because it is "the enforced default".
(so, what is easy in this regard is, that when multiple threads try to fire their Progress- or "I'm ready"-Events back into the main-thread" -
you will not have to implement any synchronizing yourself, because only "one thread at a time is let through" to the main-thread,
with its Event-Callback (due to the enforced auto-synchronizing).

- What comes as the drawback from the above mentioned "sync-comfort" is the extra-code for *async*-triggering of routines on Classes which run on different threads.
(meaning, even if your mainthread calls a method on a Class-Instance which is hosted on a different thread, the caller is by default waiting and blocking the main-
thread - until the routine on the worker-thread is exited and returns. That's what the Async-Decoupling approach (per PostMessage) avoids (when using the
small generic fDecouple-Form-Instance within the ThreadClass ... using that, the caller returns immediately (due to the nature of the PostMessage call) -
and the *reaction* to the posted message in the fDecouple-hWnd triggers in turn the (internal) execution of the Worker-Job (after the Params were buffered in the ThreadClass)

I think, the above describes the principle well enough - but please ask, if anything is still unclear.

When the bass function returns I fire an event with the result of my get stats? Is that all there is to it. Your other example has alot more going on and I cannot fully understand it, although I will keep trying.

Basically yes - there's not much more to it ... just ensure async decoupling within the called ThreadClass-Method, to proceed entirely independently (non-blocking) within your main-thread.

I'd try to integrate your bass-dll-stuff into the cThreadP-class (which is internally much simpler - but demonstrates already, how two different methods can be decoupled,
using fDecouple in conjunction with an Enum-Value.

Olaf