Format menu should use a different accelerator than 'O'

[Scott Bilas]

I noticed that I can't use the Format menu using Alt-O because it's mapped to Open Other. I think that's fine - it's consistent with VisualAssist's Alt-O.

But maybe Format could use something other than 'o'? Doesn't seem like Alt-R is in use, how about that? Fo&rmat.

Right now to get to the Format menu I have to Alt-N + (right arrow).

[Stefan]

Hi Scott,

the standard, to open an menu item, is to press Alt-key and release it, then press the second key.

The Alt-key is used to  -1) enable the menu and -2) enable the accelerator keys to access an item by pressing this key (here 'o' for Format)
Pressing Alt+second key together to open an menu item works only as long there is no other shortcut is set.


So     accelerator     Alt, O    pressed one-by-one should open Format menu
And   shortcut         Alt+O    pressed together should open opposite file pair.

HTH?

[Scott Bilas]

Respectfully, that's not the standard.

In Windows, an accelerator key is denoted with text that has an underline in it (assuming the user hasn't disabled it, which I think is the default in Vista, but anyway..). You can see it in dialog controls as well as menus. It's a general concept that means holding down Alt plus the single character that is underlined will activate the command.

On menus, there is an additional ability where you can tap Alt or F10 then hit a key and it will do the same thing. This doesn't work in dialogs, where you must always hold Alt and press the character at the same time. Users are trained to hold Alt and press the key, not tap. It's why I keep having trouble using the Format menu.

The only time I've come across Windows apps that break this standard are typically programmers' tools that are based on old DOS or unix programs such as Brief or VI. Or buggy programs where the developer is clearly not a keyboard-user.

So my expectation is that for any main menu item with an underline, I can press Alt + that key and it will bring down the menu.

[alex]

Hello Scott,

I have noticed this by myself even before your post (but this week) and have changed accelerator in Format from F&ormat to Fo&rmat already . Alt+M is also in use (as in VA) by method list.
Would be available with new beta today everning.

Best regards,
Alex.

[Scott Bilas]

Wonderful!

I don't know if I should start this as a new topic, but it's related - I noticed that there are a lot of collisions among accelerators in the menu items.

For example, in the File menu 'A' is set to Save-As, Auto-Reload, and Auto-Save. Save-As for 'A' seems to be vaguely standard for Windows apps (like Notepad) and perhaps the other two are not used so commonly as to need them? In Edit, you have Clipboard Ring and Redo colliding. There are probably many more.

I can walk through the different collisions by pressing the key several times, but this runs into a usability problem due to disabling. Sometimes one or more of these commands will get disabled, and then my memory of how many times to repeat the keypress will be wrong.

These things can be hard to catch by looking at them, and I don't remember if VS has a tool to help (you're building in MFC right?) I think I'd write a little debug-only startup routine that walks each menu, stores the letter after & and asserts that there are no dups. Hmm, I bet something like that is already on codeproject..

[Stefan]

It's a general concept that means holding down Alt plus the single character that is underlined
will activate the command.

Yes, for dialogs. But not for menus.

For menu you press Alt (well, or F10) to enable the main menu, then you can release the ALT key.
The accelerator keys are now enabled.

Now you press the accelerator key to open the menu you want,
then you press the next accelerator key to chose an item.

This is good because this way you save a few ALT+ shortcuts for other commands.

[alex]

Hello All,

Personally I do not use accelerators so my opinioin here would be valuable But I can (will) change HE behaviour in a way it would be sutable for most.

to Scott:
Yes, there are can be collision. I do not know defaults for accelerators, and what I only do some time is only go through all and try to assign as much as possible of unique accelerators in same menu. So if you can give proposal list of accelerators for menues I can updated acclerators based on it.

Yes, MFC. VS 2005. I do not know standard tool for checking.

Best regards,
Alex.

[Scott Bilas]

I'll post suggestions when I run into them. So far just the File menu has been a problem. I suggest the following changes:

Save A&ll
Print Pre&view
Print Set&up
Auto Reload - (remove accel)
Auto Save - (remove accel)
&Workspace -> Save &As...
File Propert&ies

Most of these are just for consistency with VS.NET. As for Auto Reload and Auto Save, nothing is available, but these shouldn't be used often enough to matter.

I think it's better to not have an accel than have a collision, do you agree? Especially when one command is used so much more often than the others. Collisions are very confusing.

[alex]

Hello Scott,

thanks. Changed, would be available next beta.
About collisions - do not know, as I said, I do not use accelerators
Waiting for next set from you

Best regards,
Alex.