Re: preventWindowOrdering
Re: preventWindowOrdering
- Subject: Re: preventWindowOrdering
- From: Andreas Schwarz <email@hidden>
- Date: Tue, 12 Mar 2002 17:39:47 -0800
Wow, that's supremely bizarre. Especially the three calls to -[NSEvent
dealloc]. Does this same thing happen if you don't call
-[NSApplication preventWindowOrdering], i.e. your mouseDown: does
nothing but call super?
Hmm, okay, this is making less and less sense. I checked and yes, it
does still occur even without the preventWindowOrdering. But then I
thought I'd try commenting out all the code in my mouseDown: method and
calling super to see if it still happened. It didn't! So it was
something in my code....
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??
Thanks,
Andreas
_______________________________________________
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.