views:

24

answers:

1

I need to send messages to the GUI thread which should be processed the next time the GUI thread is idle. This message can come from the GUI thread or background threads.

I tried a combination of a MachPort/Notification. But when i do a

[[NSNotificationQueue defaultQueue] enqueueNotification: my_notify postingStyle: NSPostASAP];

This is not dispatched if there is a modal dialog, i have to close the dialog before it is processed so this is not useable for me.

It's okay to not handle messages during menu selection or live resize, but modal dialogs is a little bit too much delay.

A: 

Short answer: Don't use modal dialogs.

Long answer: Modal dialogs are handled by a special run loop mode called NSModalPanelRunLoopMode, see here. To schedule a call, one way is to use performSelectorOnMainThread:withObject:waitUntilDone:modes: explained in that document; don't forget to specify the modal mode and the default mode there.

You can also use NSNotificationCenter and specify the run loop modes, see the discussion here. But it's tricky to use NSNotificationCenter from the threaded environment to start with as described here, so I don't recommend it.

On 10.6, you can also use dispatch_async.

Yuji
`performSelectorOnMainThread:withObject:waitUntilDone:` seems to suffice to report to the main thread with a modal dialog, though the documentation does not make that clear.
JWWalker
Indeed. The documentation is not clear which mode it runs when `modes:` is not used. Anyway I hate modal dialogs, so it doesn't matter for me:p
Yuji
Thanks, yes i hate modal dialogs too and got rid of most of them (i'm porting a windows/linux app so there are many). But for example NSAlert does only work modal and i want to some data update work even if this poped up. But i will ask a new question about how to write a non modal NSAlert.
Lothar