Apple

On Sep 17, 2009, at 4:44 , Franz Detro wrote:

Hi,

when porting an application from Carbon to Cocoa, I've experienced some strange behaviour of the MIDINotifyProc callback:

When a window is running in a modal NSApplication session ([NSApp runModalForWindow: nsWindow]), no CoreMIDI notifications are received until the modal session has ended.

In the documentation of MIDIClientCreate one can find:

Discussion
Note that notifyProc will always be called on the run loop which was current when MIDIClientCreate was first called.

As I understand, when running a modal session the run loop is only in another mode, it's not another run loop, right? So one should receive the notifications also with a modal dialog open.

Can somebody give me some hints here?

Hi Franz,

My understanding is that a runloop mode amounts to a name associated with a set of runloop sources -- kCFRunLoopDefaultMode is a simple convention, and kCFRunLoopCommonModes is supposed to include that and maybe a few others.

yes, this is also my understanding. I've already ran into the issue, that you do not use kCFRunLoopCommonModes, you do not receive any timer messages during modal sessions.

CoreMIDI adds its runloop source to the target runloop in kCFRunLoopCommonModes.

Is this also the case in CoreMIDI on 10.5 or was this a recent change?

I would have thought that while a modal dialog was running, it would be using one of those common modes, but apparently I'm wrong. Someone with some deeper Cocoa knowledge might be able to help us.

This would be great. Inside of our Audio and MIDI configuration dialogs, we do visualize any hot plugged Audio and MIDI devices, and this feature is broken when using Cocoa instead of Carbon.

Doug

References:
	>MIDINotifyProc and modal NSApplication sessions (From: Franz Detro <email@hidden>)
	>Re: MIDINotifyProc and modal NSApplication sessions (From: Doug Wyatt <email@hidden>)