• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: More re: Carbon Events vs Cocoa Events
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More re: Carbon Events vs Cocoa Events


  • Subject: Re: More re: Carbon Events vs Cocoa Events
  • From: Bill Bumgarner <email@hidden>
  • Date: Mon, 1 Apr 2002 17:13:36 -0500

That's a slightly different problem. For that, you need to write an Apple Event handler to pull it off. Not hard to do.

(I don't know of an API through which all events of all kinds passes. Even if there was one, it is likely low enough level that tieing it back to the specific high level event type would be a lot more work than simply creating callbacks or overriding the appropriate methods for the specific kinds of events)

See:

http://developer.apple.com/techpubs/macosx/Carbon/interapplicationcomm/AppleEventManager/
Apple_Event_Manager/Functions/Handling_App_ts_Callbacks.html

To write a general AE event filter, you would need to [likely] do something like:

- use NewAEEventHandlerUPP() to create your new Apple Event handler

- use AEInstallEventHandler() to install the event handler

extern OSErr
AEInstallEventHandler(
AEEventClass theAEEventClass,
AEEventID theAEEventID,
AEEventHandlerUPP handler,
long handlerRefcon,
Boolean isSysHandler);

You would pass the constant 'typeWildCard' for both the event class and event ID; this will cause your handler to be invoked for every single apple event received by the application. See the documentation for more information.

Unfortunaly, the UPP returned by NewAEEventHandlerUPP does not have the ability to apply a (void *)'s of random data to the UPP. The KeyChain APIs do and, as such, you can simply pass an object's id such that the callback can message directly back to ObjC.

However, it isn't hard to do. Assuming that you extended the NSApplication subclass to contain the method:

- (OSErr) sendAEEvent: (const AppleEvent *)theAppleEvent :(AppleEvent *) reply :(SInt32) handlerRefcon
{
... handle event and return status code ...
}

You could then register the following AE Event Handler such that it would invoke the above method:

OSErr MyAEEventHandlerCallback (
const AppleEvent *theAppleEvent,
AppleEvent *reply,
SInt32 handlerRefcon
) {
[NSApp sendAEEvent: theAppleEvent :reply :handlerRefcon];
}

b.bum

On Monday, April 1, 2002, at 04:15 PM, Charles Srstka wrote:

Well, I just tried it, and unfortunately, it doesn't seem to catch all events. I downloaded the NoisyApp example, and it doesn't seem to log Apple Events. If I send the AppleScript 'tell application "NoisyApp" to beep' it will send the message, and it will beep, but NoisyApp will not log the event. My little Carbon test app will log the event if I tell it to beep...

Any way to catch every event, including low-level events, high-level events, and anything in between?

Thanks,
Charles

b.bum
I ride tandem with the random....
.... things don't run the way I planned them.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: More re: Carbon Events vs Cocoa Events
      • From: Charles Srstka <email@hidden>
References: 
 >More re: Carbon Events vs Cocoa Events (From: Charles Srstka <email@hidden>)

  • Prev by Date: Re: DO question.
  • Next by Date: Saving is so darn easy!
  • Previous by thread: Re: More re: Carbon Events vs Cocoa Events
  • Next by thread: Re: More re: Carbon Events vs Cocoa Events
  • Index(es):
    • Date
    • Thread