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: Christopher Hickman <email@hidden>
- Date: Thu, 18 Aug 2005 00:16:42 -0400
That was exactly it. All I had to do was override sendEvent to send
NSScrollWheel events to my slider, and bam, it did everything I want.
Thanks.
Topher
On Aug 17, 2005, at 6:13 PM, glenn andreas wrote:
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