This is related to an earlier post of mine, but I think it warrants a new
subject. I may be expecting others to sort out my potential race conditions,
but I don't think so. The essential point here is that I need to know the
relationship between a window becoming "key" and that same window being set as
NSApp's modal window.
Specifically, what conditions must I check to be sure that my application is
displaying a modal window which is ready to handle input? The purpose is to
make sure that a secondary thread does not begin to do its work until the modal
window is up and ready to get input. This is so the secondary thread can check
whether the user has cancelled the thread operation. I want to avoid the
situation in which the secondary thread completes before a modal "cancel"
window is even up and running.
The control flow goes like this:
[NSApp runModalForWindow: someWindow]; // start a modal window
Now, the window delegate of someWindow above implements this:
- (void)windowDidBecomeKey: (NSNotification *)notification
{
NSThread *myThread = [NSThread alloc] initWithTarget....]
[myThread start];
}
That is, I do not fire up the secondary thread until someWindow has become key.
However, I see that [NSApp modalWindow] is null until after the call to
windowDidBecomeKey. In the secondary thread method I start out by polling to
see whether [NSApp modalWIndow] is non-null, like this:
// At the beginning of the secondary thread method:
while (![NSApp modalWindow]) // probably not thread-safe, but harmless??
NSLog(@"polling for modalWindow....");
// Start thread's actual work, but check whether user has cancelled via the
modal window. I synchronize
// before accessing "cancelled" below:
if (!cancelled)
{
// do the thread's work; check cancelled periodically on secondary runloop:
...etc.
My question is: Is it important for the thread to wait until NSApp has set its
modal window to proceed? Or is it enough to know that the window has become key
to ensure that secondary thread will see the "cancel" variable set by the main
thread?_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
