How to add option-or-control keyboard equivalents...

[James]

I'm having a little brain freeze trying to add some extra
option-or-control key keyboard equivalents to a carbonized app. I'd
like to add, for instance, a keyboard equivalent of "Option-Command-D"
(or Control-Command-D...either would be fine). I would also have a
"regular" Command-D keyboard equivalent for another menu item. So, how
do I properly add a special (option or control) keyboard equivalent to
a menu item? How do I both "trap" for it, and how do I properly display
the proper symbols in the menu?

I've discovered that if I enter "option-command-D" as a keyboard
equivalent in ResEdit (!) for instance, it shows up as if I'm trying to
use the character "option-D" (a lower case delta, I think)...that's NOT
what I want...no user would recognize that. I was hoping that magically
that might show up as a "D" with the special "option" symbol in the
menu.

What is the proper way to add option-key or control-key keyboard
equivalents?

THANKS!

[Gregory Weston]

In article <160720070946482209%j...@jkpoiaoq.com>,
James <j...@jkpoiaoq.com> wrote:

Well, the easiest way is to have your menus in a nib file and use
Interface Builder.

If you want to do it in code:

OSErr SetMenuItemModifiers (
MenuRef inMenu,
SInt16 inItem,
UInt8 inModifiers
);

enum {
kMenuNoModifiers = 0,
kMenuShiftModifier = (1 << 0),
kMenuOptionModifier = (1 << 1),
kMenuControlModifier = (1 << 2),
kMenuNoCommandModifier = (1 << 3)
};

[James]

In article <uce-F83FFF.1...@comcast.dca.giganews.com>,
Gregory Weston <u...@splook.com> wrote:

> Well, the easiest way is to have your menus in a nib file and use
> Interface Builder.
>
> If you want to do it in code:
>
> OSErr SetMenuItemModifiers (
> MenuRef inMenu,
> SInt16 inItem,
> UInt8 inModifiers
> );
>
> enum {
> kMenuNoModifiers = 0,
> kMenuShiftModifier = (1 << 0),
> kMenuOptionModifier = (1 << 1),
> kMenuControlModifier = (1 << 2),
> kMenuNoCommandModifier = (1 << 3)
> };

Embarrassing to admit, but still using CW and ResEdit...so doing it via
code sounds pretty good at the moment. THANKS for the point in the
right direction...

[James]

Thanks Gregory. I just tried your suggestion and it worked like a charm
and solved half of my problem! Now it's a piece of a cake for me to add
the option or control icon to a menu item keyboard equivalent. But, I
think I'm still missing something.

Does this ONLY put the icon in the menu item but NOT actually modify
the menu processing? In other words, if I had a menu resource with,
say, a "D" as a keyboard equivalent, and I then, programmatically, used
"SetMenuItemModifiers" so that the user would see the "^" caret symbol
indicating the Control modifier key should be used with a
command-D"...it would display to the user that he or she should press
"command-control-D" but when I actually press that combination, my
command handler for that menu item is NOT called. It's as if that
SetMenuItemModifiers call JUST modified the look of the menu item not
the functioning of it? What am I missing (and thanks again for your
help)...

In article <uce-F83FFF.1...@comcast.dca.giganews.com>,
Gregory Weston <u...@splook.com> wrote:

[Jens Ayton]

James:
[Menu commands with control or option]

>
> Embarrassing to admit, but still using CW and ResEdit...so doing it via
> code sounds pretty good at the moment. THANKS for the point in the
> right direction...

The resource-based way to achieve this is with 'xmnu' resources. I believe
there was a ResEdit template with the Appearance Manager SDK way back when
(along with 'dlgx' templates and similar), which you could probably still find
somewhere on ftp.apple.com.

--
Jens Ayton

[James]

Great info. Thanks!

In article <WWRmi.4241$ZA....@newsb.telia.net>, Jens Ayton

[James]

By the way, on the off chance this helps someone else with the same
problem, I thought I'd answer my own question.

The reason why even though SetMenuItemModifiers correctly added
control-or-option-type keyboard equivalents to my menu but they didn't
appear to work is that elsewhere in my code I was using MenuKey()
instead of MenuEvent(). MenuKey is oblivious to the state of the
control, option and shift keys. I switched my code to use MenuEvent(),
and now it works like a charm.

Thanks Gregory and Jens for the much appreciated help!

In article <160720071637177382%j...@jkpoiaoq.com>, James

[Jens Ayton]

James:

>
> The reason why even though SetMenuItemModifiers correctly added
> control-or-option-type keyboard equivalents to my menu but they didn't
> appear to work is that elsewhere in my code I was using MenuKey()
> instead of MenuEvent(). MenuKey is oblivious to the state of the
> control, option and shift keys. I switched my code to use MenuEvent(),
> and now it works like a charm.

Just to be clear here... I hope you know that MenuEvent and the rest of the
classic Toolbox event system is officially "not recommended" and most
definitely should not be used for new development?

--
Jens Ayton

[James]

Thanks. Yup, all of this talk is with regard to keeping an old program
working...not new development. (still using WaitNextEvent, etc...but
let's not go there! :-))

In article <Vfxni.4374$ZA....@newsb.telia.net>, Jens Ayton