Hi Tracy,

in the porting case it was left at .t., because the ported app has no activeX yet.

The "hanging" I described happened with autoyield set to .f., since this app uses the dbi-controls as well as dynazip. The "hanging" is not meant as a crashed app, but it sometimes happens, that in the running VFP code doevents is called to "put the screen right". Normally the program would run on for another few milliseconds, but the the program then just waits for another event to happen: If I touch the mouse, the CPU crunches happily on, which can be seen in the task manager.

Programmatically stuffing events just before the "doevents" didn't help in the second case: neither keyboards nor mouse moves help (always ? difficult to check <g>). We just put up a wait wind before the call, asking to move the mouse, and clear it right after the doevents. if this wait window can be seen for more than a second, it is in the "hanging state".

Before realizing that another event was needed, we had some irate calls about performance from pure keyboard users: they were waiting for minutes for the program to finish the next screen - Just your normal digital gremlins at work...

Another hint: encapsulate your doevent-calls in a method or function and add a switch to call a protocol file: if doevents is called from too many points for the same action, it will kill performance. This way you can trace the call's and can later eliminate the unneeded one's.

HTH

thomas