>>Renoir,
>>
>>READ EVENTS should be considered as an "infinite loop" - commands beyond it will never be reached, unless you "break out" of the loop. The command to break out is CLEAR EVENTS, and you must decide where is the best place to put it. In a menu-driven program, where the users can open several forms, it might be invoked from a menu command "File | Quit". If you are accepting input in a single form - the whole point of READ EVENTS being to wait for input - an alternative might also be to invoke CLEAR EVENTS from a button on the form.
>
>Ok, that's the problem. If I don't include READ EVENTS, then the data does not get sent to the port for some reason. I haven't traced yet to see why that is. If I do include READ EVENTS, then I can't stop the program. There is no user input in the program, classes or procedures.

Then you might fire CLEAR EVENTS from a Timer object, which you declare immediately before the READ EVENTS.

I think the reason your program doesn't work without READ EVENTS is the following. "oxClient" is a pointer to an object; the moment the variable "oxClient" gets out of scope - in your case, with the QUIT command - the object gets destroyed. If you are trying to communicate with a port, then pressumably the process takes some time.

Instead of a Timer, you might also use a WAIT WINDOW TIMEOUT ..., or the Sleep() API. Don't ask me how to do the latter; but the basic idea is to wait for a certain number of miliseconds before going to the next command.