On Aug 14, 2013, at 08:52 , Graham Cox <graham....@bigpond.com> wrote:
> Well, there's logically 'closed' and there's having the pixels on the screen > removed or updated. The run loop has to run for that to happen in the normal > course of things. Actually, it's going to be the Window Server that removes the window from the screen. However, it may be that ordering-out an app window triggers a run loop source or event, which in turn notifies the Window Server. If so, the 'sleep' approach isn't going to work. There may even be multiple [run-loop-triggered] interactions between the app and the Window Server, when a window closes. FWIW, I also discovered (in some roughly similar scenario) that trying to unix-sleep to allow the UI to update isn't a very successful approach. My guess, in Steve's scenario, is that a later part of the document-opening sequence is blocking the main thread for a while, but the interaction with the Window Server isn't fully finished yet, so that it gets "snagged" by the later blockage, even though the app has gone way beyond its own Open-dialog-handling code. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
