CGEventTapCreateForPSN in Mavericks+ (GetCurrentPr

问题:

I am using CGEventTapCreateForPSN to trap and filter keys for my application. I'm not interested in intercepting events for other applications. I'm pretty sure an event tap is too heavy handed for my purpose, but I've been unable to find a better way, and using the event tap works.

Specifically, this code does what I want.

GetCurrentProcess(&psn);
CFMachPortRef eventTap = CGEventTapCreateForPSN(
    &psn,
    kCGHeadInsertEventTap,
    kCGEventTapOptionDefault,
    CGEventMaskBit(kCGEventKeyDown)
        | CGEventMaskBit(kCGEventKeyUp),
    eventCallback,
    userInfo);

And my callback is handled nicely, with the events being intercepted from the current application only.

Unfortunately, all the methods to get the current ProcessSerialNumber have been deprecated as of 10.9. There is an old standard way of getting the ProcessSerialNumber to pass to other routines in the same process, with this initialization...

ProcessSerialNumber psn = { 0, kCurrentProcess };

but that does not work when calling CGEventTapCreateForPSN. The header file docs indicates as much, and the following code snippet returns NULL as confirmation.

ProcessSerialNumber psn = { 0, kCurrentProcess };
CFMachPortRef eventTap = CGEventTapCreateForPSN(
    &psn,
    kCGHeadInsertEventTap,
    kCGEventTapOptionDefault,
    CGEventMaskBit(kCGEventKeyDown)
        | CGEventMaskBit(kCGEventKeyUp),
    eventCallback,
    userInfo);

I can use CGEventTapCreate but it taps the entire host, and I would then need to filter anything not directed to my application, and the CGEventTapProxy is opaque, and I don't know how to use it to determine if its my app or not.

I have verified that the deprecated code still works, but Apple can decide to remove it at any time. So, does anyone have an idea how I should proceed for calling CGEventTapCreateForPSN in Mavericks and beyond?

Thanks!

---

UPDATE

In 10.11 (I think that was El Capitan), a new function was added. While it has zero documentation, it has almost the exact same signature as CGEventTapCreateForPSN.

CFMachPortRef CGEventTapCreateForPSN(
    void *processSerialNumber,
    CGEventTapPlacement place,
    CGEventTapOptions options,
    CGEventMask eventsOfInterest,
    CGEventTapCallBack callback,
    void *userInfo);

CFMachPortRef CGEventTapCreateForPid(
    pid_t pid,
    CGEventTapPlacement place,
    CGEventTapOptions options,
    CGEventMask eventsOfInterest,
    CGEventTapCallBack callback,
    void *userInfo);

Thus, the deprecated function is not needed since the PID can be used as the first parameter.

回答1:

I think you should subclass NSApplication and override - (void)sendEvent:(NSEvent *)theEvent method for this purpose. From docs:

You rarely should find a real need to create a custom NSApplication subclass. Unlike some object-oriented libraries, Cocoa does not require you to subclass NSApplication to customize app behavior. Instead it gives you many other ways to customize an app.

Also:

IMPORTANT

Many AppKit classes rely on the NSApplication class and may not work properly until this class is fully initialized. As a result, you should not, for example, attempt to invoke methods of other AppKit classes from an initialization method of an NSApplication subclass.

Thus, you can intercept all the events passed though your application and call custom NSApplicationDelegate-inherited protocol methods.

// in SubApplication.h

@protocol ExtendedApplicationDelegate : NSApplicationDelegate

- (void)applicationDidTrapSomeInterestingEvent:(NSEvent *)event;

@end

// in SubApplication.m

- (void)sendEvent:(NSEvent *)event
{
    if ([event type] == NSKeyDown && [event keyCode]==_someCode)
    {
      // call application delegate method
    }
    [super sendEvent:event];
}

I'm not sure if this approach solves the problem but you still make a try.

回答2:

Another way is to subclass NSApplication and override nextEventMatchingMask:untilDate:inMode:dequeue:. This sees mouse events that are not seen by overriding sendEvent:, e.g., when tracking a scroll bar. I'm not sure if it matters for keyboard events, which the question was about, but it might be of interest to others who stumble on this question.