This is interesting - I had asked for details about Delay() implementation some months ago. NI claimed that it's not simply a busy loop - that there were calls to ProcessSystemEvents within the delay. How in the world anyone would have known this, they didn't explain 🙂 But, while this might allow the application to respond to NI events, it doesn't necessarily mean that the calling thread in fact gets suspended. As a result, I've always coded my own delay routine, which loops on a Win32 API Sleep() call, with ProcessSystemEvents() in the loop. This way, the calling thread really does get suspended by the OS, and the GUI stays responsive due to the ProcessSystemEvents call.
There's a "sleep more often" switch that can be selected in the ADE - not sure just what that would do if not cause Delay() to actually suspend - maybe it's for other delay situations inherent in the run-time engine, rather than Delay() calls.
I like using Sleep() - that was you know pretty much what's going on - the thread is suspended and you don't have to infer NI library run-time behavior.