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

I agree. But I think that the way you were toying with using it was maybe a wrong direction... Calling a form method to do a routine from an OKL is still using an OKL. The VFP mechanism you guessed about to cause one form meethod to wait until another is done doesn't exist. OKLs effectively create 2 call stacks stemming from 2 user events; The original that was running, and the new branch started by the OKL. Creepy.


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

See my assertion above.

>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 "\
This brings me to another relevant point. Your wife is not seeing OKLs (as far as I know, OKL is a VFP term), she's talking about keyboard shortcuts. Windows' standards dictate that any function available as a keyboard shortcut also be available as a menu item. I don't know the logistics of your app that uses so many hotkeys, but if certain sets of hotkeys only need be available for certain forms, maybe what you need to do is push and pop utilities menus onto the main menu as your forms come and go. Then make most of these functions menu items. (If all 104 need to be accessible at once, don't ask me how to make that into a practically navigable menu). Menu shortcuts do not have the same interprocess behavior as OKLs do. They wait until the active routine is finished before beginning (they don't ignore user attempts though, they just wait, like a good little program should).

I hope you don't feel I'm leading you on a wild goose chase. To be honest, if I was asked to maintain a program that was using so many OKLs, I might just be inclined to keep it that way. Sometimes the costs of using certain no-nos does not outweigh the benefit received- you have to be the judge.

Erik Moore
Clientelligence