Link to home
Start Free TrialLog in
Avatar of GEOFS
GEOFS

asked on

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?
Avatar of Olaf Doschke
Olaf Doschke
Flag of Germany image

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.
Avatar of GEOFS
GEOFS

ASKER

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.
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?
Avatar of GEOFS

ASKER

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: http://www.windows-tech.info/9/e77cd44f264a7656.php

It seems you are not alone having Alt key problems... This link describes another interesting cause: http://www.tek-tips.com/viewthread.cfm?qid=1686293
Avatar of GEOFS

ASKER

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.
Avatar of GEOFS

ASKER

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, ...
Avatar of GEOFS

ASKER

Thanks for the suggestions, Pavel.  I'll give them a try as soon as I can.
>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.
Avatar of GEOFS

ASKER

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.
ASKER CERTIFIED SOLUTION
Avatar of Pavel Celba
Pavel Celba
Flag of Czechia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of GEOFS

ASKER

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.