MultiThreading in VB6

Ok for a few months now when I have time I have been trying all the examples out there for multi threading... This is what I have found.

The use of activeX.exe's are the best and most reliable to do this. Simply put you create a acitiveX exe file that contains a class or classes that the threaded work needs to be done in. Then you create an instance 'withevents' of that acitvex exe within you main project. Your activex.exe can now fire events and send the results, it is recommended that you start a timer for one cycle to call the intended method to avoid hangs.. etc back to the main application, and the main application can call methods that run in a seperate thread in the activex .exe. Works Great and from what I have read it is the Most reliable way to do threading in VB6.

Having said that... Here is my problem.

I am using the bass.dll library for my application. One of the external methods i use needs to be called from a separate thread so the main gui does not stop responding waiting for a return from that function. The problem is that external function call requires that the processID is the same as other calls to the library for it to work. So using the activex solution does not work because the processID of the activeX is both in a new thread but also a different processid.

I am not a expert at this at all, but I have seen some posts talking about inprocess threading using olaf's directCom.dll. I could not find examples of this. If any one has any examples or other solutions please let me know. I have looked at so many and they seem so complicated I get a bit lost. I was hoping for something an average vb6 dev can understand.

Thanks for your time.
Winston P

Quote:

---

Originally Posted by axisdj

The problem is that external function call requires that the processID is the same as other calls to the library for it to work. So using the activex solution does not work because the processID of the activeX is both in a new thread but also a different processid.

---

A process identifier is the same for all threads of any given process. Here's a description of processes and threads from Processes and Threads:

Quote:

---

Originally Posted by MSDN

An application consists of one or more processes. A process, in the simplest terms, is an executing program. One or more threads run in the context of the process. A thread is the basic unit to which the operating system allocates processor time. A thread can execute any part of the process code, including parts currently being executed by another thread.

---

This is from Process Handles and Identifiers:

Quote:

---

Originally Posted by MSDN

The CreateProcess function also returns an identifier that uniquely identifies the process throughout the system. A process can use the GetCurrentProcessId function to get its own process identifier (also known as the process ID or PID). The identifier is valid from the time the process is created until the process has been terminated. A process can use the Process32First function to obtain the process identifier of its parent process.

---

The following is from Thread Handles and Identifiers:

Quote:

---

Originally Posted by MSDN

The CreateThread and CreateRemoteThread functions also return an identifier that uniquely identifies the thread throughout the system. A thread can use the GetCurrentThreadId function to get its own thread identifier. The identifiers are valid from the time the thread is created until the thread has been terminated. Note that no thread identifier will ever be 0.

---

Can you post the declaration of that external function?

We had a discussion (along with examples) in the codebank for that recently...
http://www.vbforums.com/showthread.p...ted-Threading)

(And the term "selfhosted" does indeed mean "InProcess-Threading" with ActiveX-Exes, which is a mode
that is apparently not often used or known in the community).

So, in your shoes I'd start there, use and adapt the examples from that posting - and maybe start with
verifying in the taskmanager (when running the compiled executable), that you indeed run only one single
process with multiple threads.

If you prefer a DirectCOM.dll-based example, then I can post one too - but would like to
hear about your experience (maybe even with a small bass.dll-related sample-code-snippet) with
the "selfhosted and InProcess ActiveX.exe-threading" first - if that works well, then the adaption
to a DirectCOM.dll-based Demo would not require much from my end here.


Olaf

Bonnie West, Not sure I understand why you are posting those facts, I started my application as a standard exe, then created an external activex.exe,
which runs in a seperate processID, so my call looks like this BASS_Encode_CastGetStats(encoder(encoderNumber), BASS_ENCODE_STATS_ICE, serverPassword(encoderNumber)), where encoder is a long handle that is created in the main exe/process. So I get an error invalid handle because where I am calling the function from is in a different process then where I created it. here is a link to the response from the bass.dll creator. http://www.un4seen.com/forum/?topic=15126.0

Olaf,

I have tried to convert my project from a standard exe to an activeX.exe so that I can run my classes in seperate threads. When I tried to convert it the app started, but it was REALLY sluggish... Not sure why.

I think at this point I will have to try to use the DirectCom.dll, if possible.

Quote:

---

Originally Posted by axisdj

Olaf,

I have tried to convert my project from a standard exe to an activeX.exe so that I can run my classes in seperate threads. When I tried to convert it the app started, but it was REALLY sluggish... Not sure why.

I think at this point I will have to try to use the DirectCom.dll, if possible.

---

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. 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.

Thanks
WP

Quote:

---

Originally Posted by axisdj

Olaf,

I have tried to convert my project from a standard exe to an activeX.exe so that I can run my classes in seperate threads. When I tried to convert it the app started, but it was REALLY sluggish... Not sure why.

I think at this point I will have to try to use the DirectCom.dll, if possible.

---

"Sluggishness" - could be related to running the AX-Exe-project in the IDE (which would not work threaded then) - so please compile it, and run the binary.

I'd say, let's fix your problem with the AX-Exe-version first, before going to advanced threading-helpers as DirectCOM.dll -
For that to be "as painless as possible", you could start with an upload of what you currently have (a zipped project, which
demonstrates at least the threaded Bass-API-Call and a few "surrounding necessities", merged into one of the AX-Exe-Demos I mentioned above).

From such an example the rest would go very fast with not that many ping-pongs - Threading-topics tend to be complex
- best to express them in code (for a concrete example), that'd be a "less mistakable form of communication" then.

Olaf

Quote:

---

Originally Posted by axisdj

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.

Quote:

---

Originally Posted by axisdj

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

Quote:

---

Originally Posted by axisdj

Bonnie West, Not sure I understand why you are posting those facts, I started my application as a standard exe, then created an external activex.exe,
which runs in a seperate processID, ... So I get an error invalid handle because where I am calling the function from is in a different process then where I created it.

---

Well, you didn't make it very clear in your original post that you were using two processes.

Well Olaf,

You are the man.. after much struggle I got it going.

Found a couple of things strange. The createObject call had to be in the form_activate function, tried it in the load and did not start a new thread, not sure why.
Also had delay all my bass_init stuff until after the create object call, or else when the creatObject was called all handles/links to bass library was lost/reset.

I have one function that still uses doevents, and I notice it is slower to refresh than before when it was a standard.exe, any idea why? May have to implement that function in another thread as well.

After six + months finally got it, will run it for days and see if there are any problems.

Thanks Very Much for your wisdom and talent!

After more than 1 year of my app running 24/7, not a single problem with threading. The ActiveX.exe multithreading approach is a bulletproof way to run multiple threads in-process and out of process using vb6!!!

Thanks Again Olaf!!!

Quote:

---

Originally Posted by axisdj

Well Olaf,

You are the man.. after much struggle I got it going.

Found a couple of things strange. The createObject call had to be in the form_activate function, tried it in the load and did not start a new thread, not sure why.
Also had delay all my bass_init stuff until after the create object call, or else when the creatObject was called all handles/links to bass library was lost/reset.

I have one function that still uses doevents, and I notice it is slower to refresh than before when it was a standard.exe, any idea why? May have to implement that function in another thread as well.

After six + months finally got it, will run it for days and see if there are any problems.

Thanks Very Much for your wisdom and talent!

---

i would suggest not to go with vb6 .it is useless in vb6 . if you want to work with Multithreading go with vb.net or c#.
with the help of backgroundworker . easy to work with multithreading . see the following link .hope it might help .


http://msdn.microsoft.com/en-us/libr...code-snippet-2

@firoz.raj - Did you miss the part where axisdj said the VB6 approach has been working flawlessly for over a year? Useless indeed!

Quote:

---

Originally Posted by firoz.raj

i would suggest not to go with vb6 .it is useless in vb6 . if you want to work with Multithreading go with vb.net or c#.
with the help of backgroundworker . easy to work with multithreading . see the following link .hope it might help .


http://msdn.microsoft.com/en-us/libr...code-snippet-2

---

Attachment 120575

Be careful here ;)

Quote:

---

Be careful here

---

I hope . expecting from you will delete your post . it is not good if someone by mistake did some typing mistake . you will take out fire from your mouth .


when i see the title of the post Multithreading. even i did not go through schmidt post #3,7,8. i replied that is totally not acceptable . I realized and feel shame on making comment .