Greetings Erik...

>
You can't use stuff like THIS, THISFORM, and THISFORMSET in an OKL- those keywords only have scope inside an object method, and OKL routines are not methods.
>

ah yes, I actually twigged that myself and changed the call to the actual formset name thus:

on keylabel f9 FORMSETNAME.HOTKEY.CHOOSEGO.CLICK()

but it still protested it couldn't find 'HOTKEY'. I don't understand why - given that the form HOTKEY was active, and part of the formset.

>
I don't use formsets, so I can't help you there, but if it were a form, oyu could call a routine that loops through _SCREEN.Forms looking for your form and call the method that you got from that object reference

ON KEY LABEL F9 DO RunFormMethod

PROCEDURE RunFormMethod
FOR EACH oForm IN _SCREEN.Forms
IF oForm.Name = "MyForm"
oForm.SomeControl.SomeMethod()
ENDIF
ENDFOR
>

that option doesn't appeal. Looks time consuming and having to do it for 100+ hotkeys sounds about as attractive as toothache.

The problem, from what Jim has to say seems to be that buttons can only be addressed on a currently active and visible form - the logic of which I can understand. If so, it is irrelevant that my previous attempts can't find the active HOTKEY form because even if they did, they couldn't activate the non visible button.

So I tried this instead - create a new form method which is called by the OKL and which then runs the actual hotkey routine.

This works OK but my question is whether this is enough to overcome the interprocess problem. My rationale is that vfp must have rules internally which govern potential event processing conflicts and presumably won't allow a form method to be executed until previously called processes are complete. I can understand that the OKL will interrupt whatever code is running but, hopefully, if it calls a form method, it will be 'held up' until it is safe to proceed.

>
Keep in mind, I still don't approve of the use of OKL here... :-)
<

I'm open to suggestions for alternatives but they must be able to be activated by the keyboard and not the mouse. Users happy with zapping through various procedures in fractions of a second will not accept (and I have no intention of even suggesting) switching to methods which take 5 to 10 times as long for skilled keyboard users.

One question which my wife pointed out seems pretty relevant. If OKLs are so troublesome, how come so many OKLs are routinely defined in most mainstream windows applications? I've just check MS Word, ferinstance, and, without too much effort, found over 20 available hotkeys whilst creating a plain ornery document... In CorelDraw, over 36 hotkeys are defined.

These are just the ones you can find on the main menus. Now there's a question - do OKLs defined through menus have the same interprocess problems? If not, twould be a doddle just to define a hotkey menu with the OKLs defined on it... Menus have a major advantage over buttons because we can assign key combinations like CTRL+ALT+C rather than just "\
Harry