>I'm testing a long running vfp program and found these problems
>
>Wait window messages freeze (in different parts during different runs)
>Added debugout message, but it also freezes.
>I set escape on, but program doesn't respond to ESC
>Added saving message to disk which shows that program continues to run
>Finally process finishes correctly
>
>It's almost like it locks screen and keyboard out.
>
>I have windows 7 64 bit and VFP sp2. Any idea what may be the problem?
>
>TIA,
>
>Alex


Windows uses a message queue to communicate system messages to an application. Normally a tight loop is used to receive and dispatch those messages. The way Visual FoxPro is written, it is blocking. This means that when Visual FoxPro begins processing a program, there are certain operations which are atomic (they run consecutively) without servicing the message loop. Since no messages are being received by Visual FoxPro it appears to lock up. The keystrokes you type, the mouse clicks and so forth, they are all in the message queue waiting to be serviced. Windows observes this queue getting bigger and bigger, and notes the time since the last message was read from the queue... if enough time passes Windows concludes the application is hung up.

It's a bad design, one of the weaker points of Visual FoxPro. But, for most applications it's not an issue. Issuing DOEVENTS in any loops that process data can help. Issuing DOEVENTS FORCE may sometimes be needed. An alternate design is to kick off an external program that handles the hard processing, while maintaining the original "launcher app" as a separate process that's not bogged down with processing. The external program will simply run the process and notify back in some way once it achieves completion that it is now done. In this way, the UI of the app never appears to be bogged down, and the application is effectively working in a multi-threaded capacity (albeit in multiple processes).