>In a nusthsell you don't want to be a "CPU hog" by having busy-wait loops (i.e. tight loops where you're checking for a specific set of condition -- e.g. readiness for data from device or process). Of you're in a situation where you're in some loop waiting for something, you might as well relinquish the remaining part of the timeslice. This might actually speed things up, since it could very well allow the other process that you're waiting for to complete as it gets more CPU cycles to complete its task. Admittedly I've been guilty of a fair amount of badly-behaving code like that back in the PC/MS-DOS days. That was mainly since you'd only have one program running at any time (and in the case where you'd launched a different program, in most cases i'd be a blocking call -- so your program would always sleep and not get resume running until the called program ran to completion), and more often than not, you had actual hardware (that operated independent of the main CPU) like UART to handle various tasks (nowadays in Windows many devices ave been virtualized as software -- so it's *very* important you don't "starve" them and cause the system to come to a grinding halt).

In my code blocks I do this:

DECLARE Sleep IN WIN32API INTEGER milliseconds

* Do the thing

* Wait
DO WHILE condition_is_unsatisfied()
    DOEVENTS FORCE
    Sleep(10)
ENDDO

In that way, I both allow VFP to process its messages, and Windows to have more CPU time for other tasks.