Clarion is the only Application Generator that produces identical 16 and 32 Bit programs with a simple click of the mouse. 16 Bit Clarion programs have always been able to use features that other RAD environments can only implement in 32 bit programs.
Clarion uses the Accept Loop to accomplish much of its magic. In order for Background Threads to operate, they must have an Accept Loop. This does not mean, however, that a Window Procedure can enter into an Endless Loop and never check the Message Queue for Windows Messages. In Clarion, Timer Events are used to implement Background Processing.
The File Transfer routines are written in "C", not in the Clarion Language. They do not have a Clarion Window associated with them and hence do not have an Accept Loop. For this reason, the Transfer routines must take control over your Clarion Program while a File Transfer is in progress. If they didn't disable the Application Windows, your users would be able to select Menu Items, but the Clarion Program would not respond because an Accept Loop is not being Cycled.
Even if the Transfer Protocols were written in Clarion, they would have to use a Timer Event in order to operate in the Background and this would not be acceptable since the transfer would be horrendously slow.
It should be noted that the File Transfer routines do operate in the background, to a certain extent. This is evident by the fact that you can move a Window on top of your Application (while a transfer is taking place), move the Window away, and your Clarion Program will repaint its Window. The Transfer routines were designed to allow the Clarion Program to process its Messages.
In 32 Bit programs, CLACom Starts a Background Thread that does the actual File Transfer. Background threads are being utilized, they just may not be apparent.