Multithreading with parameter disposal

Hi,

I want to realize a multithreading application in VB (6.0 SP6). Well thats not that hard... basically I'm calling the API function CreateThread with the AddressOf the function that I wanted to call. Now the question(s):

1. How do I fill the function parameters of the calling function (When there are some)?
2. And how to evaluate the returning parameters of the function?

Thanks for you help!

Best regards,
KK
KriskraAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

junglerover77Commented:
Please view the following article authored by Matthcw Curland, a member of Microsoft's Visual Basic Development Team.

Never Call CreateThread from Visual Basic

A Win32 thread can't participate in COM programming without making an explicit COM library call to either CoInitialize or CoInitializeEx. These functions associate a thread with an apartment. It's illegal and usually fatal for a thread to participate in any COM-related activities before calling one of these functions. Fortunately, the COM+ runtime makes this call for you when it creates a thread. If you're creating a Standard EXE or an ActiveX EXE, the Visual Basic runtime makes all of the required calls to CoInitialize behind the scenes.

Working directly with Win32 threads and COM apartments is difficult and, for all practical purposes, beyond the capabilities of the Visual Basic programming language. However, when Visual Basic 5 first shipped, many unfortunate programmers tried to directly call the CreateThread function in the Win32 API by using Visual Basic's new AddressOf operator. The programmers found that they could successfully call CreateThread but that their applications often died strange and mysterious deaths.

The problem with calling CreateThread is that it creates a new Win32 thread that knows nothing about COM or apartments. It's therefore illegal to use this thread to invoke a method on a COM object. This creates quite a problem because all Visual Basic objects, including forms and controls, are also COM objects. Such an object can be directly accessed only by the thread running in the object's apartment. When the newly created thread tries to change a value in a text box, the application crashes. This is a pretty good reason to never use CreateThread directly from Visual Basic code.

A determined Visual Basic programmer with knowledge of COM's threading models might try to take things to the next level. You can associate a thread with an STA by calling a function such as CoInitialize directly. However, once you associate the thread with an apartment, the complexity increases. For instance, you're typically required to write code for marshaling interface references (which are really interface pointers at this level) from one apartment to another. If you pass the interface references in a COM method call, the proxy and the stub are created automatically. However, if you pass them using another technique, the requirements increase dramatically. You must make two complicated calls to the COM library-a call to CoMarshalInterface to create a stub in the object's apartment and a call to CoUnmarshalInterface to create a proxy in the caller's apartment. What's more, you also have to know enough about COM to decide when these calls are necessary. Add in the complexities related to the rules of COM+ and contexts, and you should come to an important conclusion: Never call CreateThread from Visual Basic. If you really need to spawn your own threads, you should be using C++ and you should know a great deal about the underlying plumbing of COM.

I must admit that this entire sidebar is just an opinion. Some of the icons of the Visual Basic world, such as Matt Curland, advocate spawning threads directly from Visual Basic code in the manner I just described. Matt can tell you about the details of this undertaking in a book he's written titled Advanced Visual Basic 6: Power Techniques for Everyday Programs (published by Addison Wesley).

If you feel comfortable with all the COM details I covered in Chapter? and you're looking for more in-depth coverage, Matt's book can take you to the next level. Matt has worked on the Visual Basic team for quite a few years and he has intimate knowledge of how the Visual Basic runtime interacts with the COM library. He describes many techniques that involve calling into the COM library directly from Visual Basic code.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.