Hi Ed,
I never said the timer suspended VFP. It is exactly that reason why things don't get bogged down when using a timer. A message is input to the queue. It is then up to VFP itself to process what's in the queue. If a developer codes things in such a way as there is never a break/pause in processing or if they never explicitly tell VFP to process queue messages (DOEVENTS), well they are just SOL, IMO. Live and learn! They won't don't it too often before they learn or they won't get anything done.

BTW, I will disagree with you about using a timer in a DLL. Certainly you can do that. Any UI control can be used in a DLL as long as it doesn't display any output. I've made forms DLLs before the advent of the session class. IAC, the timer is not a UI control. It has no visible element so there is no conflict when including it in a DLL.

*snip*
>That's why I at least do not advocate using the native timer for non-UI based event polling. If you need VFP to pop it's head up once every 2 minutes to look to see if something has changed - a file has magically appeared, for example - you're far better off having no UI element active at all, and using something like the Sleep API to make VFP go idle for a period of time - so it doesn't get dispatched to burn up cycles that, while might be constructively used in a UI-oriented transaction environment, take cycles away from other things that might be running on the system. There's a noticable difference in performance if you:
>
>

DECLARE Sleep IN WIN32API INTEGER dwMilliseconds
>
>* Nice, un-UI-ish code
>
>DO WHILE .T.
>   =Sleep(120000)  && go idle for at least 120 seconds
>   IF <i>jRandomEvent occurred</i>
>      * <b>Do something useful</b>
>   ENDIF
>*  DOEVENTS()
>*  If you don't uncomment the DOEVENTS(), the app won't respond to the UI,
>*  but it will check for and process the event every two minutes, and might
>*  respond to the UI in the code to <b>Do something useful</b>
>ENDDO

>
>And instancing a timer object, setting its interval to 120000, starting it, at each timer event checking for jRandomEvent occurred to happen and if so, calling some code to Do something useful. In fact, a little careless coding starting your timer and not sitting at a READ EVENTS to watch the world go by could mean that you never respond to the timer. A block of code like:
>
>

DEFINE CLASS MyTimer AS TIMER
>   Enabled = .f.
>   INTERVAL = 120000
>PROCEDURE Timer
>   IF <i>jRandomEvent occurred</i>
>      * <b>Do something useful</b>
>   ENDIF

    if <flag to exit from checking> then
        THIS.Enabled = .F.
        clear events
    endif
>ENDPROC
>ENDDEFINE
>
>* the programmer now loses it's "sanity"
>
>oMyBadTimer=CREATEOBJ('MyTimer')
>oMyBadTimer.Interval=120000
>oMyBadTimer.Enable
>   cMyRandomVariable = 'I saw nothing!'
read events

>
>Further, the Sleep() based code could be made into an in-proc server (.DLL) - the timer-based version has a UI element (the timer!) so it can't be a .DLL...
>
>Makes you wish you sold wall cushions for a living!

Have you seen any performance differences using the above modifications?