>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...

Several things ahead: you may rewrite your hotkey definitions to get into the form class definition, in the KeyPress - that way you're safer from the, ahem, "possible future funkiness", and your hotkeys which are defined to work on a form will work only while that form is active. If it weren't so, you could bring up another form, or a report preview, whatever, while your form is running, and your OKLs would still apply.

Another potentially dangerous which burned my fingers with OKLs was Pentix. It was a Tetris clone, played by several guys, who usually stuffed keyboard repeat accelerators as TSRs, so I'd get full keyboard buffer of keypresses if I didn't release the key immediately. Now if it was a key with an OKL definition, a funny thing occured - the OKL was called for the first keypress, then it was called again for the next one, before any lines of its first instance were executed. It actually did nothing, but put an enormous amount of calls on the callstack, which usually broke up with "Do nesting too deep". I've tried several things, like Clear Typeahead, Set Typeahead to 0 etc as the first command in my OKLs, but they never got executed - the keyboard buffer took precedence, i.e. an OKL call interrupted execution of the same OKL call before it's first line.

Now this was happening in DOS days, and I've not checked this in VFP, simply because I don't use OKLs anymore (maybe sometimes, during a browse - and scoped to that browse only - but not in production, only in some of my tools). The keyboard settings, however, are done at Windows or BIOS level now, so you can't control it. Do a test: define an OKL, and keep its key pressed. See what happens.

Another thing: I've done a "redefine all keys" routine once, back in FP2.0 - and it was dead slow, took more than two seconds to execute. It may be fast enough now, but - why should it run in the first place? Use KeyPress, it runs only when it has to. If your keys are mostly Fx keys, you can cut short through the long Case in KeyPress, like this:

case nKeyCode<0 && a-ha! an F key
do case
case nKeyCode=-1 && F2
...
endcase
case nKeyCode=whatever etc etc
otherwise
DoDefault(nKeyCode, nShiftAltCtrl)
endc

Pair this with the other message. I hope I didn't ruin your week.