Does VB6 Timer control create separate thread?

Question

Does the VB6 Timer control create a separate processing thread when it starts?

Answer 1

VB6 Timer controls are not some kind of busy-wait loop running on a background thread. They don't really "run" at all.

As far as I can tell when you set Enabled = True (or change Interval if it was 0) the control makes a SetTimer() call. When you set Enabled = False (or set Interval to 0) it makes a KillTimer() call.

The normal VB6 message loop (which of course runs on the UI thread) handles incoming WM_TIMER messages by dispatching them to the associated Timer's event handler code. Thus the code inside your event handler runs on the UI thread, blocking further message processing until exit. Interval seems to be chopped to an unsigned 16-bit value - for legacy reasons (16-bit VB and Windows)?

Anything like a busy-wait loop coded in your program (all of your code runs on the UI thread) will of course block message processing, giving the illusion that Timers do not "fire." Since WM_TIMER is a low priority message they do not stack up deeply in the message queue while you have the UI thread bound up:

The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.

Answer 2

No, the timer runs in the same thread as the window procedure, and thus the Visual Basic 6 program. This means that if you do processor intensive operations, you cannot rely on the WM_TIMER message being processed.