Re: Cocoa equivalent for 'InstallApplicationEventHandler'
Re: Cocoa equivalent for 'InstallApplicationEventHandler'
- Subject: Re: Cocoa equivalent for 'InstallApplicationEventHandler'
- From: Vikram Sethi <email@hidden>
- Date: Sun, 21 Feb 2010 16:35:49 +0530
Hi all,
Thanks for the prompt responses.
As Jesper mentioned, I would like my app to work on 10.5 as well. I forgot
to mention that in my earlier mail.
>> "Ordinarily it doesn't make any sense to type into an app that has no
open windows. If you have special hot keys that should do something even in
this state (like maybe the Help key opening your help window), you can
create menu items for those actions and set those keystrokes as their
shortcuts."
Yes, I would agree that it is not generally a good practice. However, there
are certain things that I would like the app to do in a no-window state for
which tapping into the app would make sense.
I believe that overriding sendEvent seems to be better choice as of now.
Thanks again,
Vikram
On Sat, Feb 20, 2010 at 11:21 PM, Jesper Storm Bache <email@hidden>wrote:
> Your comment only pertains to the addGlobal...
> You can use addLocalMonitor to only snoop on events in your process. From
> the header:
> =====
> Use +addLocal to install an event monitor that receives events before
> they are dispatched by -[NSApplication sendEvent:]. In this case, your block
> should either return a valid NSEvent (which may be the same as the incoming
> NSEvent, or may be a newly created NSEvent) to cause the event to be
> dispatched, or it may return nil to stop dispatching of the event. Note that
> your handler will not be called for events that are consumed by nested
> event-tracking loops such as control tracking, menu tracking, or window
> dragging; only events that are dispatched through -[NSApplication
> sendEvent:] will be passed to your handler.
> =====
>
> addLocalMonitor is 10.6 only and you can view it as a somewhat similar to
> installing a handler on the Carbon event dispatcher.
> If you want a solution that works on systems before 10.6, consider either
> overriding NSApplication sendEvent, or using a local (process specific)
> event tap.
>
> Jesper
>
> On Feb 20, 2010, at 4:08 AM, Uli Kusterer wrote:
>
> > On 20.02.2010, at 12:53, Tom Davie wrote:
> >> You want NSEvent's
> >>
> >> + (id)addGlobalMonitorForEventsMatchingMask:(NSEventMask)*mask*
> handler:(void
> >> (^)(NSEvent*))*block*
> >> *and*
> >> *
> >>
> >> + (id)addLocalMonitorForEventsMatchingMask:(NSEventMask)mask
> handler:(NSEvent*
> >> (^)(NSEvent*))block
> >
> > Nope, that's the wrong choice. This would give him copies of events sent
> to *other* applications as well (hence the "global").
> >
> > The sendEvent override seems like the most workable solution to me so
> far. Though I'd suggest not doing the work directly in your application
> instance. Instead, forward the event to your delegate. That way, you can use
> the same NSApplication subclass in your other apps.
> >
> > Cheers,
> > -- Uli Kusterer
> > "The Witnesses of TeachText are everywhere..."
> > http://groups.yahoo.com/group/mac-gui-dev/
> >
> > _______________________________________________
> >
> > Cocoa-dev mailing list (email@hidden)
> >
> > 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:
> >
> > This email sent to email@hidden
>
>
--
Ξ √ίkř@m Ŝεth! Ξ
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden