On 2011 Oct 18, at 21:58, Ken Thomases wrote:
> "Should" in what sense? It's a type indicator, that's why it starts with
> "type".
Well, it's an enum symbol in a system header. But forget it. I made a mistake
there. James was correct to begin with. It should be typeEventHotKeyID.
Sorry
On Oct 18, 2011, at 11:21 PM, Jerry Krinock wrote:
> P.S. typeEventHotKeyID should be eventTypeHotKeyID
"Should" in what sense? It's a type indicator, that's why it starts with
"type". The type it is conveying in this case is EventHotKeyID, the type of
your hotKeyID parameter (and of the val
On 2011 Oct 18, at 13:22, James Walker wrote:
> The only documented parameter in the kEventClassKeyboard /
> kEventHotKeyPressed Carbon Event is
>
> kEventParamDirectObject (in, typeEventHotKeyID)
> The ID of the hot key that was pressed.
>
> That's the ID that was passed to RegisterEve
On 10/18/2011 1:00 PM, Jerry Krinock wrote:
I've registered a handler for global hot keys with the Carbon Event
Manager, using InstallEventHandler(). However, I'd like the user to
be able to specify *two* different global hot key functions. Thus,
in my callback/handler, I need the key code and
I've registered a handler for global hot keys with the Carbon Event Manager,
using InstallEventHandler(). However, I'd like the user to be able to specify
*two* different global hot key functions. Thus, in my callback/handler, I need
the key code and modifier flags of the event, to determine w
