>>Yes, but indirectly - you could call an out-of-process server, for example. if all I needed were lightweight comms in the background and I weren't running anything processor-intensive, MSCOMM32 could probably handle it in conjunction with VFPCOM to link VFP code to the OnComm event, but it's still a single thread of execution; VFP wouldn't interrupt a single atomic VFP command (for example, a horrible non-optimizable query) to execute an event handler; it only responds to events between lines of code...
>
>Right, but that's as close as we can get in VFP.

Agreed - if you can spare the memory, running two VFP sessions and using a common semaphoring scheme to sync them will probably be easier to implement.