Re: NSApplicationMain() doesn't set NSApp to my subclass
Re: NSApplicationMain() doesn't set NSApp to my subclass
- Subject: Re: NSApplicationMain() doesn't set NSApp to my subclass
- From: glenn andreas <email@hidden>
- Date: Wed, 17 Aug 2005 17:13:08 -0500
On Aug 17, 2005, at 3:29 PM, Christopher Hickman wrote:
Okay, it turns out that it is correctly setting NSApp to an
instance of my
subclass. I only thought it wasn't because the backtrace was showing
-[NSApplication run] and not -[SWLApplication run]. I guess that's
because
I didn't need to override the super's implementation of run. The
other
reason I thought it wasn't working was that the point of me
subclassing
NSApplication was to take the NSScrollWheel events and pass them
off to
another object, so that scroll wheel events would be application-
global. It
isn't working. Even though my NSApp object implements
scrollWheel:, it is
never called when the scroll wheel scrolls.
Am I going about this wrong? Here's what I want to happen.
It's a bit convoluted with lots of special cases (see <file:///
Developer/ADC Reference Library/documentation/Cocoa/Conceptual/
BasicEventHandling/Concepts/ActionEventMsg.html#//apple_ref/doc/uid/
20000897>):
NSApplication’s sendEvent: analyzes the event and handles some things
specially—key equivalents, for example. Most events, however, it
passes to the appropriate window for dispatch up its responder chain
using NSWindow’s sendEvent: method. NSResponder’s default
implementations of all event methods simply pass the message to the
next responder, so if no object in the responder chain does anything
with the event it’s simply lost. As mentioned before, an NSView’s
next responder is nearly always its superview, so if, for example,
the NSView that receives a mouseDown: message doesn’t handle it, its
superview gets a chance, and so on up to the NSWindow. If no object
is found to handle the event, the last responder in the chain invokes
noResponderFor:, which for a key-down event simply beeps. Event-
handling objects (subclasses of NSWindow and NSView) can override
this method to perform additional steps as needed.
Note that it says that events go App->Window->First Responder-
>Superview....->Windows Content View=Stop.
Actions are dispatched differently (those various things that are
declared "- (IBAction) doSomething: (id) sender") - they're the ones
that use "the full responder chain".
So what you'll need to do is override NSApplication sendEvent: and
check to see if it is a scroll wheel event, if you want the
application to handle scroll wheels. If you want some views to
handle scroll wheels, and other cases where there is nothing to
handle it to fall back through to the application, you'll probably
have to use a category to replace the existing behavior of
NSResponder scrollWheel: to do something like:
if ([self nextResponder])
[[self nextResponder] scrollWheel: event];
else
[NSApp scrollWheel: event];
(note that using a category to replace an existing method is often
not a good idea, because you need to make sure to replicate all the
existing functionality, as well as provide your new functionality,
since there is no easy way to get the original method to call it like
you can for subclassing, and if there is another category that is
also trying to replace the method, well, "there can be only one").
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
Widgetarium | the quickest path to widgets
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden