Multithreading with VB6

Peter

unread,

Jul 10, 2004, 5:29:15 PM7/10/04

to

Dear All

Can anybody please recommend either a good example how to use the Win-APIs
to have multithreading support in a VB6 project.
More better would be if anyone knows a VB class that uses the APIs and
offers Multithreading support.
Regards
Peter

MikeD

unread,

Jul 10, 2004, 6:58:24 PM7/10/04

to

"Peter" <-> wrote in message news:eZQavTs...@tk2msftngp13.phx.gbl...

The ONLY reliable way to multithread in VB is by using ActiveX EXEs. VB does
not support multithreading. That's not to say you can't do via the API, but
you're taking a VERY big risk that the app will be unstable. VB6 simply
wasn't designed to support this. In fact, VB5 is actually more stable using
the Win32 API for multithreading than VB6 is (but it's not advisable under
VB5 either).

Perhaps you should explain your situation and/or circumstance as to why you
think you need to implement multithread support. There is most likely an
alternative that will work adequately. People hear the term "multithreading"
and read a little about it and think "Hey! That'd be great for what I want".
Then they focus all their attention to getting multithreading to work in
VB....usually with disastrous side affects (like the program crashing). The
real truth is if you design your program properly, multithreading will not
help that much. Obviously, how much mutlithreading can benefit depends on
what you're doing.

Mike

Peter

unread,

Jul 11, 2004, 10:18:45 AM7/11/04

to

Hi Mike

Thanks for your detailed answer.
Well, at the moment I don't have a project where mt is required so I can't
give you any details on this.
I have asked the question to the newsgroup because I have seen how easy mt
can be used in vb.net.
During this investigations I found out that mt could be very useful for my
further VB6 projects so I thought it would make sense to find a way how to
have mt support in VB6 as well.
I know you can add mt support to a vb6 program by using the windows APIs but
I like to have the same comfort way as it is in vb.net where you just use a
class. I have heared that vb.net has just "wrapped" the mt APIs into the
class so this should be possible for VB6 as well,shouldn't it?
So I am looking now for such a class for VB6 where the mt apis are just
wrapped inside.
I am now a little bit confused because you wrote that the mt-apis do not run
very stable with vb6 programs???
Why? Is it a bug in VB6? Is it just from your experience or is this problem
known at microsoft?
However, I will continue searching for such a mt class, I can't believe that
nobody else has a requirement for such a class.
Regards
Peter

"MikeD" <nob...@nowhere.edu> schrieb im Newsbeitrag
news:O8zI$DtZEH...@TK2MSFTNGP09.phx.gbl...

Schmidt

unread,

Jul 11, 2004, 12:27:54 PM7/11/04

to

"Peter" <-> schrieb im Newsbeitrag
news:uTdn2H1Z...@TK2MSFTNGP10.phx.gbl...

> I am now a little bit confused because you wrote that the mt-apis do not
run
> very stable with vb6 programs???
> Why? Is it a bug in VB6? Is it just from your experience or is this
problem
> known at microsoft?

The straight use of the Threading-APIs is not possible because of the way VB
deals with COM and Thread-Local-Storage (google for this one).
That means in practise, to initialize you have to create a COM-Object on the
new thread first -> the difficulty is, that you must do this *without* using
the VB-Runtime-Libs. This is mostly done with Helper-DLLs written in another
language or (if you would like to do this with pure VB) per TypeLib-declared
API-Calls.

> However, I will continue searching for such a mt class, I can't believe
that
> nobody else has a requirement for such a class.

Of course there are MT-Implementations for easy use within VB.
Here's a link to my free Helper-DLLs (together with sample Code).
It comes in form of a ThreadPool-Class, wich encapsulates all the
complicated stuff (Message-Queues, centralized ThreadEvent-Handling,
Locking, Priority-Handling, SharedMemory, etc.)

www.datenhaus.de/Downloads/dh_ThreadPool.zip

Olaf

Peter

unread,

Jul 11, 2004, 1:22:40 PM7/11/04

to

Hi Olaf

Many thanks for your answer.
I will download your helper-dll and will have a look at it. Thanks again.
One more question to you, I am sure you can answer it:
Is there a way to write a multithreaded vb application without the use of an
external activex or dll or is there allways such an external component
required?
Regards
Peter

"Schmidt" <s...@online.de> schrieb im Newsbeitrag
news:OanSNO2Z...@TK2MSFTNGP12.phx.gbl...

Schmidt

unread,

Jul 12, 2004, 4:45:35 AM7/12/04

to

"Peter" <-> schrieb im Newsbeitrag

news:OuG7nu2Z...@TK2MSFTNGP09.phx.gbl...

> Is there a way to write a multithreaded vb application without the use of
an
> external activex or dll or is there allways such an external component
> required?

No, you could write a multithreaded Standalone-App, if you switch the
Project-Type to ActiveX-Exe.
Under www.datenhaus.de/Downloads/VBThreading.zip you can find another
example, wich works as a multithreaded Standalone-App (after compile).

But why not deploy an App, based on COMponents.
It's easier to add/change functionality on a Component-based approach.
Dll-Hell is no problem anymore.
The dh_ThreadPool-Components (from my first link) don't need any
registration on the customer-machine, just as your self-compiled
Thread-Dlls, wich are loaded by dh_ThreadPool.
So there's no need, to put all functionality into one single Exe, as long as
your additional Binaries are in the App.Path.

Olaf

Ken Halter

unread,

Jul 12, 2004, 11:29:54 AM7/12/04

to

Peter wrote:
> Hi Mike

>
> I have asked the question to the newsgroup because I have seen how easy mt
> can be used in vb.net.

...and I imagine threading will be fully misused in .Net. Mud pies are
easy to make too but that doesn't mean they need to be on every menu.

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..

Dick Grier

unread,

Jul 12, 2004, 12:59:31 PM7/12/04

to

Hi Ken,

>>
...and I imagine threading will be fully misused in .Net. Mud pies are
easy to make too but that doesn't mean they need to be on every menu.
<<

Sure, it is possible to misuse it. However, (IMO) multithreading is one of
the most compelling features that we get with .NET. With power comes
responsibility. This is not a new concept.

Its use isn't for novices. But, as a tool, it can be really valuable.
Should it be in the "toolbox?" Sure. Like a hammer... Every fastener is
not a nail.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

Ken Halter

unread,

Jul 12, 2004, 1:33:07 PM7/12/04

to

Dick Grier wrote:
> Hi Ken,

>
> Sure, it is possible to misuse it. However, (IMO) multithreading is one of
> the most compelling features that we get with .NET. With power comes
> responsibility. This is not a new concept.

True... fwiw, I've been writing basic/VB apps for quite a long time and
have exactly one app that benefits from multiple threads <g>... and even
then, the marshalling overhead's making me consider a re-write.

> Its use isn't for novices. But, as a tool, it can be really valuable.
> Should it be in the "toolbox?" Sure. Like a hammer... Every fastener is
> not a nail.

And... everything that can drive a nail's not a hammer (can't convince
the wife though <g>)

> Dick

John Eikanger [MSFT]

unread,

Jul 16, 2004, 6:00:09 PM7/16/04

to

Hi, Peter

All of the previous feedback is quite correct. Threading in VB6 is
difficult and not very stable. If you wish to learn more about threading
in VB6, check out Chapter 13 of "Advanced Visual Basic 6" by Matt Curland.
The techniques are not supported, but they can be made to work.

Hope this helps,

John Eikanger
Microsoft Developer Support

This posting is provided “AS IS” with no warranties, and confers no rights.