One way to avoid the problem you are describing is to have a global to check if your application is still running. Based on that global, time consuming operations can return and you can shut down quickly while still freeing resources.
You can make a macro like this:
#define process(x,y) {double tin; tin = Timer(); while(Timer() - tin < (x) ) {ProcessSystemEvents(); if( (y) ) return(-1); }}
and a global:
int no_longer_running = 0;
then you can use it like this:
process(duree,no_longer_running);
and in your quit function add:
no_longer_running = 1;
QuitUserInterface();
This implementation is "sloppy" in its timing. That is the ProcessSystemEvents() might take longer than you think so that the duree might be overshot by some number of milliseconds.
Delay() is the best for short, accurate times; it keeps the processor loaded checking the time without allowing other inputs from that thread.
SDK sleep() is good if you do not need to process system events and dont want your program to appear to be a hog, but might be a little less accurate since in essence you are waiting for a time slice from the OS.
If you have a function which uses a lot of process(x,y) or ProcessSystemEvents() in a single threaded application usually you will want to ensure that only one instance of it can be launched by the user.
For the RS232 application it is often easier to use callbacks with install com call backs. That way your application can spend most of its time idling at RunUserInterface() except when it is doing something. If you can make up a state machine based on the data you receive you will be better off than sending some text, processing system events for awhile, and then trying to read something. Instead send some text and note what is expected return. When some text arrives the callback will be called, use the note for what text is expected to guide the processing of the incoming data.
