Shortcut keys don't work in VFP9 program.

All of our VFP9 programs use shortcut keys defined with "\<" to provide quick keyboard access to buttons, entry fields and the like.  The shortcut keys in all of these programs have always worked as expected ... until now.  One recently built program has decided to ignore its shortcut keys.  This is especially puzzling because this new program is a slightly modified copy of an older program whose shortcut keys work fine.

I've compared the form properties, system settings and the like between the two programs, but can't find anything that would explain this behavior.  Does anyone have any idea what might cause shortcut keys to be ignored?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Olaf DoschkeSoftware DeveloperCommented:
The only thing I find in the VFP help is: "If an access key for your menu system doesn't work, look for duplicate access keys."

I doubt this explains no access key workng. A broken keyboard (eg ALT key) also wouldn't explain why one application works and not the other.

Keypress events suppressing keys? Keypreview having any influence? I do know some of the very standard hotkeys like copy&paste via ^C ^V don't work, if no corresponding system menu or shortcut menu is defined, but I don't assume there has to be something to make the access keys work. The ones on captions near to text/list/edit/comboboxes need to have the right tab order (just one lower then the target control), but captions of buttons should at least work.

Bye, Olaf.
You are not disclosing what hotkeys on what places are you talking about so the answer cannot be accurate.

Hotkey can be consumed in the KeyPress event of the form or in whatever control is on the form. Form's KeyPreview property also affects hotkeys processing.

You may watch key press events in the debugger and look what control processes the KeyPress event.
GEOFSAuthor Commented:
Thanks to both of you for your feedback.

Olaf:  Most of the hotkeys are defined on buttons and work as they should in other programs, including the one on which this misbehaving program is based.  It isn't a keyboard issue because the keys fail to work on at least 3 different computers and, as you say, the other programs work on those same computers

Pavel:  Hotkeys are used on four forms in this program and in its "parent", the program that was used as the base for this one.  Almost all of the hotkeys are defined on buttons:  \<Quit and \<Next on form #1; \<Close, \<Data, \<Preview and \<Output on form #2; \<Save and \<Cancel on form #3; and \<Save and \<Cancel on form #4.  Only one form has KeyPress code and it is the same in both programs.  KeyPreview is false for all forms in both programs.  We'll give the debugger a try and let you know what we find.
Introduction to Web Design

Develop a strong foundation and understanding of web design by learning HTML, CSS, and additional tools to help you develop your own website.

Does this happen when you build a new EXE with all files recompilation?

Do your forms or buttons use some form or button class?

What happens when you set focus to some button (without button click) on the form #2, e.g. \<Output,  and then press C  or  Alt+C ? Does the Click event fire on \<Close button?
GEOFSAuthor Commented:
No special classes are used, just the VFP base classes.

If I tab to a button to give it focus, then key that button's shortcut (e.g., Alt+C), nothing happens.  However, pressing the hotkey letter of that button or any other button without the <Alt> key "clicks" the corresponding button.  This seems oddly familiar.
So this means "some hotkeys work"...  Alt+<key> can be consumed by hotkeys in the menu. Does your menu use Alt+C, Alt+D, Alt+P, etc.?

Even when we did not explain different behavior of your app you may look for alternate ways of hotkeys processing. One example is e.g. here:

It seems you are not alone having Alt key problems... This link describes another interesting cause:
GEOFSAuthor Commented:
i think it means "all hokeys sorta work".  A bit more experimentation confirmed that, as long as focus was held by an object that doesn't accept keystrokes (e.g., a button), pressing a hotkey letter without the <Alt> key produced the hotkey behavior, but pressing the normal hotkey sequence (e.g., Alt+C) did not.  This does suggest that a menu is active, I think, but this little program has no menu, as such, just a main form that opens a second form that opens a third or fourth.

However, there is a menu defined in the program that is opened by right clicking on the grid in the second form.  This "context menu" provides functionality to add, edit or delete items from the grid list and used uses keys A, C and D as hotkeys.  Is it possible that this menu is eating the other hotkeys even when it is not open?  And why doesn't this happen in the other program?  

I'll try removing the hotkeys from this menu to see what that might change.
GEOFSAuthor Commented:
I see I that I made up a new word, "hokeys", in my last comment.

I removed the "\<" from the menu bar prompts of the context menu.  That got rid of the underline on the first letter, but didn't change the behavior of the menu.  Pressing the key corresponding to the first letter of each item still selects the item.

I keep coming back to the fact that the <Alt> key combinations work as expected in the program used as the basis for this new program, but there seems to be no difference in the programs that would explain the difference in behavior.
Microsoft code is going its own way sometimes...

What you could try is:
1) Restart your computer (if you are not doing it regularly)
2) Recompile all your project files
3) Try KeyPreview = .T.
4) Test different language and keyboard layout in Windows
5) Send some code/executable to allow this bug reproduction in our environment
6) Create a small new project with just one form inside and check the hotkeys behavior. Then add context menu, then add other stuff from the previous project, ...
GEOFSAuthor Commented:
Thanks for the suggestions, Pavel.  I'll give them a try as soon as I can.
Olaf DoschkeSoftware DeveloperCommented:
>Is it possible that this menu is eating the other hotkeys even when it is not open?  And why doesn't this happen in the other program?

Actually, if you have no menu (sysmenu) of _screen or a form, you even can't use many standard hotkeys like CTRL+C,CTRL+V (Copy&Paste). A context menu, even if not visible/active, allows reenabling these hotkeys, but that means it adds hotkey behaviou, I don't see it swallows any other hotkey behaviour.

What swallows key behaviour might be a ON KEY setting or you have a NODEFAULT in Keypress events, but you can't swallow any ALT key combination, eg ON KEY LABEL ALT ... isn't possible, gives a syntax error, as ALT always has to be combined, eg ALT+F1 or ALT+C or whatever.

Bye, Olaf.
GEOFSAuthor Commented:
At the suggestion of one of my other developers, we tried adding a SET KEYCOMP TO WINDOWS command at the beginning of the program.  That re-activated the hotkeys, which will allow us to continue implementation of this program.  However, it doesn't tell us what caused the keys to be inactive.
LOL, I've been searching help to find this command because I've used it when porting FoxPro DOS to Windows but I didn't find it last week... I simply forgot this setting name...

OK, SET KEYCOMP can be in config.fpw or even in Windows Registry but VFP application compiled into EXE does not read Registry values automatically.

SET KEYCOMP is set to WINDOWS by default if your application used SET KEYCOMP TO DOS then it must be in the CONFIG.FPW or you are executing the app from VFP IDE which can read the value from Registry.

You may find this setting in VFP Tools - Options - General Tab.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
GEOFSAuthor Commented:
It turns out that there is a configuration file, CONFIG.FPW, in the old environment we're using to test this program and that this configuration file contains the statement KEYCOMP = DOS.  It is a little embarrassing to admit that we had forgotten about this option for configuring FoxPro and so didn't think to look for a CONFIG.FPW.  Besides that, neither the developer nor I had run across the KEYCOMP option before.  In any case, the problem is actually solved now, not just covered with a bandaid.

Thanks again for your suggestions.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.