On Jun 30, 2015, at 12:55 , Sean McBride <s...@rogue-research.com> wrote: > > However, the panel itself doesn't always actually get visually removed from > the screen before my loop spins around again and displays another open panel.
In the dialog APIs that have a completion handler, there’s a free ‘orderOut:’ after the handler returns, if it didn’t do that already. I’d assume that this is is what’s internally causing the ‘orderOut:’ to happen later than you wish, and of course you have no direct control over this. Possible workarounds: 1. Don’t use a loop, but rather than a chain of dispatches. That is, put the prompt code in a block that takes some parameters, and at the end of the block do a dispatch_async (dispatch_get_main_queue (), …) of the block with some new parameters. This should queue your next dialog after a block that’s been queued to do the ‘orderOut:’, which will defer the new dialog until the old one is gone. (This is basically your ‘sleep’ workaround, but without any delay.) 2. Use ‘beginWithCompletionHandler:’ instead of ‘runModal’. The only downside is that it’s not modal, so the dialog could get hidden by other windows of your app, if the user clicks on the wrong thing. _______________________________________________ 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
