Hey Ken, Thanks for your detailed response.
It does. Mission Control is part of the management of the desktop > environment. The concept of focus doesn't apply to Mission Control. It's > at a "meta" level conceptually above that. It's a means by which a > different application can be made active, but it merely showing does not > change any application's active status. That would be OK if it at least didn't tell me that my window was the keyWindow. According to the documentation<https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/Reference/Reference.html#//apple_ref/occ/instm/NSApplication/keyWindow>, the key window is supposed to receive keyboard events. If it doesn't, then there's something wrong. You should rely on key repeat events to let you know that you need to > continue to respond to the key press. For mouse events, you should request > periodic events. Could you point me towards the APIs that let me get key repeat and periodic mouse events? The docs say you would receive key events only "if accessibility is enabled > or if your application is trusted for accessibility access (see > AXIsProcessTrusted)". (By the way, your link goes to the wrong part of > that page.) Yeah, I at least get mouse events with this though, even though accessibility isn't enabled. I don't get them if Mission Control/Command Tab are active. Sorry about the faulty link, it seems like links in Apple's documentation don't work properly. You might try a Quartz event tap at kCGSessionEventTap. I suspect that > -addGlobalMonitorForEventsMatchingMask:... is equivalent to > kCGAnnotatedSessionEventTap, and maybe that's the wrong place for Mission > Control. (Although I would hope that its events would be routed in the > usual manner. *shrug*) I haven't tried this. I suspect it would be the same as the Cocoa API, and in any case, requires my application to be accessibility enabled. I'm not sure why you're looking to treat Mission Control differently than > all Mac apps have treated the application switcher for its entire history – > which is to say, ignored it. It doesn't pose a problem to most applications because in most applications, there's not much damage you can do by having a mouse button held down indefinitely. The application I'm working on uses a mouse to drive a robot. Having it held down when the user doesn't intend it to is a safety hazard. Best, Daiwei On Fri, Oct 12, 2012 at 3:12 AM, Ken Thomases <[email protected]> wrote: > On Oct 2, 2012, at 2:06 AM, Daiwei Li wrote: > > > When Mission Control runs, it prevents applications from receiving > keyboard > > and mouse events. It also leaves the last application running thinking > that > > it still has focus. > > It does. Mission Control is part of the management of the desktop > environment. The concept of focus doesn't apply to Mission Control. It's > at a "meta" level conceptually above that. It's a means by which a > different application can be made active, but it merely showing does not > change any application's active status. > > > This is a problem for me because I don't receive keyUp > > or mouseUp events if I start Mission Control with a mouse button or a key > > held down and my application will behave as if that mouse button or key > is > > held down. > > First, it seems somewhat unusual for Mission Control to be engaged in the > middle of a mouse-down/mouse-up or key-down/key-up sequence. Second, you > shouldn't usually care if a long time has passed since you saw a key-down > event without seeing a corresponding key-up event. You should rely on key > repeat events to let you know that you need to continue to respond to the > key press. > > For mouse events, you should request periodic events. I don't know if > those are suspended while Mission Control is active. > > > > I would like a way to either read both keyboard and mouse events even > when > > Mission Control is active, or a way of detecting that Mission Control is > > active. Ideally, I would like to be able to do the latter since I > > effectively can't use my application when Mission Control is running. > > > > I've tried a couple of things with no luck: > > > > 1. Use addGlobalMonitorForEventsMatchingMask to register a global > > monitor for keyboard and mouse events. This captures mouse events (but > not > > keyboard events, although the > > documentation< > http://developer.apple.com/library/mac/#DOCUMENTATION/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/Reference/Reference.html%23//apple_ref/c/econst/NSLeftMouseUp > > > > says > > keyDown events should be sent to the global monitor) when I switch to > > another application, but Mission Control doesn't seem to let events > > propagate to global monitors. > > The docs say you would receive key events only "if accessibility is > enabled or if your application is trusted for accessibility access (see > AXIsProcessTrusted)". (By the way, your link goes to the wrong part of > that page.) > > You might try a Quartz event tap at kCGSessionEventTap. I suspect that > -addGlobalMonitorForEventsMatchingMask:... is equivalent to > kCGAnnotatedSessionEventTap, and maybe that's the wrong place for Mission > Control. (Although I would hope that its events would be routed in the > usual manner. *shrug*) > > > 2. Check [[NSRunningApplication currentApplication] {isActive, > > ownsMenuBar}]. Apparently, my application is active even though it's > not > > receiving events! > > 3. Check [NSApp keyWindow] != nil. Apparently, one of my windows should > > be receiving key events. None of them are. > > 4. Check if Mission Control is one of the running applications returned > > by [NSWorkspace runningApplications]. Mission Control does not show up > > in this list when it's running. > > None of these surprises me. First, Mission Control isn't an app. It > doesn't appear in the Dock or the Command-Tab application switcher, etc. > Second, whatever is running that GUI is probably running for the whole > duration of your login session. (It's probably run by the Dock process.) > Speaking of the Command-Tab application switcher, Mission Control is > analogous to that. When that's up, it receives events instead of your app. > It's not an application unto itself, it's part of the desktop environment > which is managing applications and their windows. When the application > switcher is up, your app does not lose active status. Etc. I'm not sure > why you're looking to treat Mission Control differently than all Mac apps > have treated the application switcher for its entire history – which is to > say, ignored it. > > Regards, > Ken > > _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
