Hi Harry,

I've been following this and have nothing new to offer but one suggestion...

I think you'll want to check out the "flow" of the keying real early in your testing. Remember, menus cascade and I do believe that you have to go through all of the "levels" to get at the particular key combination that you want.

good luck with this (and I must admit that I didn't really 'get' why it was that JimB's suggestion to use the Form's KeyPress event wouldn't do the job you need).

Jim N

>>>
>>>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.
>>
>
>yes I think I've finally grasped that!
>
>>
>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.
>>
>
>and why it needs to be avoided...
>
>>
>>>
>>>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.
>>
>
>yes indeed - my sloppy nomenclature
>
>>
>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).
>>
>it doesn't need to be because...
>
>> 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).
>>
>
>which is what I finally guessed must be happening. Providing you include the hotkey definition in each relevant menu item, the user never needs to see the menu (unless they've forgotten the hotkey and want to look it up)
>
>I reckon this has got to be the right answer...
>
>>I hope you don't feel I'm leading you on a wild goose chase.
>
>au contraire - by charging blindly up the wrong paths and having you drag me back, I've not only figured out the probable solution but also learnt more significant details of how it all fits together. Extremely valuable stuff.
>
>> 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.
>>
>
>I've started creating the menu. And in reviewing my existing hotkeys, I find I've exaggerated the number. Ferinstance my F9 hotkey actually gives you a choice of up to 10 further options. My previous hotkey list itemised them all - thus counting one hotkey as 10. When you take that kind of overstatement into account I'm actually only using about 40, not over 100. Many of them are specific to various parts of the app, but that can be built into the menu by 'skipping' for various conditions. All in all, the menu route seems absolutely bleedin obvious (once you've stumbled across it!)
>
>Many thanks
>
>Harry