>It would be OK, if both processes share the time slices of one CPU.
>The important part is, that one proccess uses CommTools to make communication via the serial ports. If have a few loops for retry in that procedure. Sometimes the program has to go through all the loops to complete the procedure and during that time I have a hour glass on the screen and the user can not make any entries.
> What can I do to avoid this?
>

I don't know about CommTools, but with VFP5 and VFP6, you can attach VFP code to the events of an ActiveX control using VFPCOM (download from msdn.microsoft.com/vfoxpro/downloads). I've used it succesfully to attach code to the MSCOMM32 control's OnComm event to service low-speed, intermittent serial devices without having to continuously poll in a VFP application.

You're going to find it much easier in all probability to run two separate sessions of VFP, one of which handles servicing the comm stuff using CommTools, and setting up a semaphoring system that can be intermittently polled by another VFP session. The semaphoring mechanism is nothing more than something visible to both VFP sessions that will allow the process servicing the serial port to let the other VFP session know that it has work for it to do. You could use a shared file 9add a record to indicate that somethign needs to be done, and delete it when the job is finished) or you could use a more sophisticated mechanism like MSMQ (an inter-process message API for sending esages between programs.)

>Thanks in advance
>Angela