• 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: preventWindowOrdering
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: preventWindowOrdering


  • Subject: Re: preventWindowOrdering
  • From: email@hidden
  • Date: Tue, 12 Mar 2002 19:09:29 -0800

After fifteen minutes of uncommenting bits and pieces at a time, I found
which block of code was causing the weirdness. Not that it's helped me
at all: the block of code causes that effect even if it is AFTER the
call to [super mouseDown:]!!! How can it affect the program before it
even gets to that line of code? I tried setting a breakpoint in there
to see if it was somehow called later on during the strange stuff [super
mouseDown:] is doing, but it doesn't.

A code snippet:

NSLog(@"Here");
[super mouseDown:theEvent];
NSLog(@"Here 2");

while ([theEvent type] != NSLeftMouseUp) {
theEvent = [[self window] nextEventMatchingMask: NSLeftMouseUpMask |
NSLeftMouseDraggedMask];
// Checking for drag here
}

It is the while loop that is causing the problem (the app will log
"Here" and then just freeze until you click in the view a second time,
at which point it will log "Here 2" and continue on as if nothing ever
happened). But of course that doesn't make sense...

I'm going to check now to see what (if anything) in particular in the
while loop is doing this. Has anyone else ever run into this??

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.
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...?

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.

  • Follow-Ups:
    • Re: preventWindowOrdering
      • From: Andreas Schwarz <email@hidden>
  • Prev by Date: Bundle, Wrappers, whatever
  • Next by Date: Re: NSComboBox initialFirstResponder and nextKeyView Outlets
  • Previous by thread: Re: Bundle, Wrappers, whatever
  • Next by thread: Re: preventWindowOrdering
  • Index(es):
    • Date
    • Thread