Eric - don't do this to me!!

>
Harry- I'm glad you are getting close to solving your problem. I have one more thing to throw in though...

I would try to avoid using and OKL to do anything. OKLs are interprocess calls, which means that pressing the key can interrupt a running process and rn the code right in the middle of something else. Not always bad, but can cause some strange things to happen.

I would put a button on the calling for and make its caption "<\A" so it could act as your hot key. You can move it off of the visible portion of the form if you want. This way, your form is always being called from a form method... maybe this will take some inconsistencies out of the behavior you are observing.
>

Ouch, ouch, ouch!

This would be seriously bad news!

I have defined no less than 104 hotkeys into my application and my users would Lynch me if they even read the above! Keyboard actions are up to 1000% more efficient with skilled users doing bulk data input and there is no way in the world they (or I) could accept the loss of the hot keys. We'd have no option but to stay in dos if it was that serious.

However, we've been using bits of the vfp version on a standalone basis in trials and training, and, so far, thats one of the areas where we don't have a problem. All the hot keys are doing their jobs with remarkably little fuss. However, whether we'll survive the transition to multi-user so easily is a horse of a different feather! So y' got me worried dude!

So - is there any call -even a low level call to the system - that can tell us when form processing has ended and it is safe to proceed? If so I can insert such a call at the critical part of the hot key code...

Or can you create an invisible but active form just full of "hotkey buttons" appropriately defined which could part of each relevant formset...

If not, anyone got any other suggestions?

:-(

Harry