>Dragan, > >OKL's will burn you!!!!!! They interrupt running code when they are >pressed. Instead of doing what you are doing look at my earlier reply in >this thread and use the form's JeyPress event to trap the keystrokes and >act on them. Thisw ay the keystorkes are only processed when no code is >running and only when that form has focus. Burn? I've already had worse than that. Having this f3f4 method triggered via OKL was just the quickest workaround until I find a better method - I'll probably move it into the form class's KeyPress, which is already in use (intercepting ESC). In one of the worst scenarios, I've had DnArrow OKLed to a routine which skipped a record down and refreshed a browse window (three years ago, fp2.0). The trick which made it unusable was that accepting a keypress takes precedence over any other system event, and then triggering a new OKL call takes precedence over execution of any program line... so there was no way to be quick enough and prevent stacking of OKL calls in case someone stepped down to it - it invariably broke with "do nesting too deep". I wander if ever anyone succeeded in suppressing a double call of an OKL routine. Just set the keyboard repeat speed high enough and repeat delay low enough, in case the machine is too fast, and then try. In this case, the OKL may remain for a while, because it's used for copying the value from the previous record or setting the Carry on/off status for the active control, so user expects to see the textbox value change, and waits for the change, and nothing else happens at the moment. In any other situation I really think twice, give myself a good kick in the head, visit the toilet, go for a walk, and if I still don't find anything better, then and only then use an OKL.