Re: Are NSWindowDidResizeNotifications permitted to arrive on the heartbeat thread?
Re: Are NSWindowDidResizeNotifications permitted to arrive on the heartbeat thread?
- Subject: Re: Are NSWindowDidResizeNotifications permitted to arrive on the heartbeat thread?
- From: Milton Sagen <email@hidden>
- Date: Tue, 16 Aug 2005 14:51:39 -0700
I can't answer the "Why", I can only say that for me it doesn't
matter. If my handling of the notification needs to happen on the
main thread then I check to make sure the notification is happening
on the main thread and if it isn't I'd have the object handling it
call performSelectorOnMainThread:withObject:waitUntilDone: passing NO
for the waitUntilDone: parameter. Although in this particular case it
might be better to call
performSelectorOnMainThread:withObject:waitUntilDone:modes:.
On Aug 16, 2005, at 14:16, Tim Gogolin wrote:
Fair enough, but that only re-phrases the question:
Why does Appkit *POST* the notification in a non-main thread if the
notification is intended for the application to handle?
(I presume NSWindowDidResizeNotification is fair game for
applications to listen to)
FYI: I don't think my code is doing anything weird with threads
that would cause this... The triggering event seems to be:
1) I present a modal dialog (with a default button).
2) Appkit notices a window "resize" (presumably the creation of the
newly posted dialog) while in the heartbeat thread to animate the
default button.
3) Appkit posts the notification while in the heartbeat thread.
Still seems kinda iffy to me...
-- Tim Gogolin
On Aug 16, 2005, at 4:03 PM, Milton Sagen wrote:
the first line in
http://developer.apple.com/documentation/Cocoa/Conceptual/
Notifications/index.html#//apple_ref/doc/uid/10000043i
states: Regular notification centers deliver notifications on the
thread in which the notification was posted.
On Aug 16, 2005, at 13:52, Tim Gogolin wrote:
Does AppKit send UI notifications on non-main threads? Most of
what I understand about AppKit lore says to do all UI tasks on
the main thread only.
I wanted to listen to NSWindowDidResizeNotification notifications
on a specific window and (through a bug on my part) wound up
listening to ALL NSWindow resizes (I accidently passed 'nil' for
the 'object' parameter). I was very surprised to get a
NSNotification selector called on the UI heartbeat thread. I've
fixed my code to only listen to the window I care about and life
is good again (the notifications seem to be coming on the main
thread now), but I'm still very curious... does listening to
NSWindowDidResizeNotification for all NSWindows (by passing 'nil'
for the 'object' param) intentionally result in getting some of
those notifications while executing on the heartbeat thread?
Seems like kind of shaky behavior on AppKit's part.
// pseudo code
- (void) setPanel: (int) whichPanel contentView: (AgValuePtr)
contentValue
{
NSWindow* aWindow = [ foo getSpecialWindow ]; // my bug
resulted in this being nil!
[ [ NSNotificationCenter defaultCenter]
addObserver: self
selector: @selector(specialWindowDidResize:)
name: NSWindowDidResizeNotification
object: aWindow ];
}
-(void) specialWindowDidResize: (NSNotification*) n
{
// Code that was unhappy when executing on a non-main thread
}
Is this a bug in AppKit, or is this permitted behavior?
(I could probably change my code back and get a stack trace
showing the problem if that would help diagnose it)
--
Tim Gogolin
Adobe Systems
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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