If VB6 does not handle multithreading, how are events handled?

Hello all, I'm having some trouble understanding how VB6 handles "asynchronous" events when it does not support multithreading.

In my case, I am porting a VB6 application to C#, and have found that in the VB6 application, there are several Global and Public variables that are shared between several event handlers. These event handlers include button Click events, Winsock DataArrival events, and a Timer event.

How is access to these variables synchronized across all of these events? Or, is this application written incorrectly?

[...]

Hi FSW_Person,

Welcome to VBForums. Yes dz32 hit the nail on the head. Nothing happens until one event completes execution. Then, whatever next event is on the queue gets fired, and so on.

The only exception to this is when DoEvents is used, which is highly discouraged. DoEvents pauses the code at the DoEvents line, goes to see if other events are on the queue, executes them, and then returns to the event with the DoEvents line, completing that code. More often than not, using DoEvents just makes a mess of things.

Now, regarding global/public variables, I don't really see the issue. If they're set by the thread, wherever it happens to be, they're set. And then, subsequent events will see those changes.

Not to be patronizing, but it all seems fairly straightforward to me.

Best Of Luck,
Elroy

EDIT1: Just to be clear, the DoEvents statement does not start a new thread. It just pauses the current code and goes and executes other events, and then returns to complete the code where it was executed. DoEvents is really only useful (in my opinion) to monitor a "Cancel" button on a long-running procedure. You may want to terminate it before it completes, but the "Cancel" button won't click until the long-running procedure has completed without that long-running procedure occasionally executing a DoEvents statement. And even then, one should be careful that nothing but the "Cancel" button can cause an event.

There is nothing new or special there, that's how programs work in Windows and similar OS GUI subsystems. This is not unique to VB by any means, and even the Great Pretender VB.Net and C# work the same way... just as a program in C, C++, Delphi, etc. does.

In a desktop application any additional threads are "deaf and dumb" (as in not in communication with the user) worker threads. A process only has one user interface thread under normal circumstances. Worker threads are much more like a command-line application thread or a batch thread.

In most higher-level languages you do not write the event loop code, it is provided for you by the runtime library that you use. That saves you from writing a lot of boilerplate code in every program.

All of the code you write consists of subroutines invoked by the message loop. As these are dispatched they should do their job as quickly as possible and then return control to the caller. The caller (message loop) can then dispatch the next and then the next until the message queue is empty, where it waits for queue insertion before dispatching events again.

The best way to get an understanding of this is to write a small Windows program in plain old C.

FSW_Person,

You also said something about the timer. However, it also follows all the same rules that we outlined. In other words, a long running procedure (without DoEvents) will effectively disable the timer so long as that long running procedure is still running. Other than DoEvents, there's no intra-program software interrupt in VB6.

Now, you may wonder how Windows maintains it's multi-tasking abilities with VB6. But that's at an entirely different level. That's why I said intra-program software interrupt. Windows can still certainly suspend execution of a VB6 program, do other things, and then return to execution where it was suspended. Again, that's at a level beyond any single VB6 program.

All The Best,
Elroy

Quote:

---

Hello all, I'm having some trouble understanding how VB6 handles "asynchronous" events when it does not support multithreading.

---

Supports.
COM uses a messages queue in STA apartments. When you call CoInitialize it creates a hidden window to communicate between apartments. If you receive an event from a COM object in the other apartment COM packs parameters and translates them to caller apartment (marshaling) then wait until the event handling has been finished. All events/calls in STA are synchronous ones.

Quote:

---

In my case, I am porting a VB6 application to C#, and have found that in the VB6 application, there are several Global and Public variables that are shared between several event handlers. These event handlers include button Click events, Winsock DataArrival events, and a Timer event.

---

All the events you wrote are synchronous ones because all VB6 objects live in STA. I mean synchronous in term of single threading. The process of communicating between objects in different apartments i shortly described above.

Quote:

---

How is access to these variables synchronized across all of these events? Or, is this application written incorrectly?

---

All data are synchronized in STA.

Thread Local Storage is another factor here.