How does the Timer Control work?

Does anybody know how the Timer Control works in relation to the current process? In particular, suppose it fires while I am writing something to disk or memory. Does the processor ...

1. Stop what it is doing instantly (hopefully at the end of a VB6 instruction rather than after an asm instruction) until the timer has finished its new task?

2. Proceed with both tasks simultaneously? Ie asynchronously

3. Continue with what it is doing until it encounters DoEvents and then stop?

4. Something else?

Thanks in anticipation
Bob

VB6 is single threaded.
Events are processed at a point in the VB process loop, and a timer tick is an event.

If your code is in a loop (doesn't exit a top level procedure), then VB will never get to process events, so the form image won't update, and the timer event will not be processed.

You can manually force VB to process events in a loop by doing a DoEvents call.

VB is not designed to loop user code endlessly. The code should be designed to be event driven, responding to mouse, keyboard, timer, etc. events.

If you need to have a continuous game loop to maximize utilization, then you will need the Doevents call to allow event processing.

"Behind the scenes", I'd imagine that the control wraps a windows timer which posts WM_TIMER messages to the queue. You could investigate this, if you're interested, by setting up a message loop and a window proc (see here (http://www.xtremevbtalk.com/showthread.php?t=78306) and here (http://www.xtremevbtalk.com/showthread.php?t=213459)) and examining what passes through.

While you're running tight (no DoEvents) user code, the messages simply queue up. Once the app returns to an idle state, it catches up. Whether old WM_TIMERs should be processed as usual or be treated as expired depends on how the control is designed and/or the property settings.

Passel, many thanks. So, provided I put DoEvents in a sensible place it will act in a sensible fashion. That is helpful and is as it should be, on reflection.