Re: preventWindowOrdering
Re: preventWindowOrdering
- Subject: Re: preventWindowOrdering
- From: email@hidden
- Date: Tue, 12 Mar 2002 21:16:58 -0800
It sounds like when you call [super mouseDown:], whatever that ends
up at decides to run a tracking loop of its own. This is not
uncommon. So my guess is that your code is not regaining control
until after the mouse-up has occurred. theEvent, however, still
contains the mouseDown event (or may contain some other event, as I
have heard a rumor that NSEvent objects get reused by the system), so
you enter your tracking loop, which proceeds to wait for another
mouseUp.
Ah, that explains part of it, thanks. But why does [super mouseDown:]
decide to run it's own tracking loops some of the time (only when that
particular bit of code is after the [super mouseDown:] call) and not
any other time? That doesn't make sense.
BTW, I discovered the culprit to be the "theEvent = [[self window]
nextEventMatchingMask: NSLeftMouseUpMask | NSLeftMouseDraggedMask];"
line; without that there's no problem, though of course my while loop
doesn't function properly. But as I said this line comes AFTER the
[super mouseDown:] call and I fail to see why it's existence should
affect anything before the program reaches it.
I guess I'm not clear on why you're so sure you're affecting the
behaviour of super's tracking loop. It sounds to me like super is
running its tracking loop regardless of whether your code is there or
not. It is your code, after the call to super, that is making things
behave wonkily. Or, depending on what you're trying to do here, it is
the simple fact that you're calling super in the first place that is
making everything behave wonkily.
If you're doing your own tracking loop, why are you calling super?
Calling super implies that you want super to do its own tracking of
the mouseDown, whatever that might be. NSResponder's default
implementation passes the call up the responder chain, so any
superview that wants to handle the click will take it and do as it
pleases. It sounds like that's not what you want...?
I was told to do it after [NSApp preventWindowOrdering]. That doesn't
do anything at all unless I call [super mouseDown:] afterwards. Am I
doing something wrong?
Probably. Calling super is not requisite. I think the other poster
was assuming that you wanted to get your standard, inherited click
behavior, but simply wanted the click not to bring your window forward.
This was why they suggested calling super. But if you want to be doing
your own tracking loop (and it sounds like you do), then there's no
reason to call super. Make your call to [NSApp preventWindowOrdering],
do your tracking loop, and return.
In other words, to get [NSApp preventWindowOrdering] to do what you
want, simply insert it into whatever mouseDown processing would
otherwise be going on. If you wouldn't call super without the
-preventWindowOrdering call in your code, you shouldn't start calling
super just because you've added that call.
It sounds like you might want to read up on NSResponder, the first
responder chain, and tracking loops in the doc. You seem to be a little
unclear as to what exactly your call to super is doing, here.
Ben Haller
Stick Software
_______________________________________________
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.