>> In that case I'd guess you might want to use method swizzling on >> -[NSEvent dealloc]: >> >> http://www.cocoadev.com/index.pl?MethodSwizzling >> >> Beware that swizzling is a powerful and dangerous technique, and you >> want to code your override with the utmost caution, but it's a great >> way to intercept methods like this.
>> Mike > Since the event is application-defined, any handler will, of course, also be > application-defined. > Can't you handle this in the handler? Or, alternatively, in an override of > -[NSApplication sendEvent:]? > Regards, > Ken That's what I'm currently doing - releasing the referenced object in an override of sendEvent. The problem is that events don't always go through there (in a modal tracking loop, specifically) so I need handle that case too. Why? Well, it's too complicated to go into here but I actually play all kinds of games with event handling in order to emulate the Windows API, which has a rather different view of the world. It's not my most favourite piece of code. Strangely, if you post a mouse or keyboard event to the input queue, the event that is eventually delivered is a copy of the original, rather than the event you actually posted. Why this should be I don't know but it makes life much harder for me. So I shall ponder my options. What I have works, but I have had one crash report from the field (just one) where my referenced object pointer was obviously stale so there must be a little loophole in there somewhere. Thanks for the input guys, much appreciated. Regards, Paul Sanders. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
