Handling host menu enabledness from Cocoa based plugin in OSX

0
votes

I'm a Windows developer developing a Cocoa-based plugin for a MacOS host application (Premiere Pro). At certain times, the host blockingly calls into my plugin callback function, at which time I'm supposed to show a modal dialog, only returning once the dialog is dismissed.

I've already managed to put up the modal dialog, nicely parenting it to the host's main window via:

// Get this from the host
NSWindow* parentWindowHandle = ...;

// Create this one myself, or rather have the Juce framework create it for me
NSWindow* ourWindowHandle = ...;

// Connect the two
[parentWindowHandle addChildWindow:ourWindowHandle ordered:NSWindowAbove];

This works nicely; my dialog is always on top of the host, and the host's main window is disabled.

But...

The host's menu is still active at that time. And worse, it is even responsive as well, which allows the user to start host functionality while my modal dialog is up, which ultimately results in their modal open next to mine and a certain hang (forever spinning beachball).

I realize it's quite possible I'm attacking this the wrong way being a Windows developer and all, but then again maybe this is just an oversight in the host app?

And an almost certainly related question which might be a clue as well: Copy/Paste via the keyboard just doesn't work in text boxes in my plugin modal dialogs, right until I manually click the host's "Edit" menu open, after which keyboard shortcut pasting works again. For the rest of the host's lifetime no less, even when my dialog gets dismissed and a new one created later on.

EDIT

I've tried [[NSApplication sharedApplication] runModalForWindow: myDialogWindow] as advertized in the linked question, but it blocks right on that line. Seems legit, since it should enter a modal loop. However, my Cocoa window is created for me by a GUI framework (Juce; it's a multiplatform project), so I have no control over how the messages for the window are handled. So I guess the above way is unusable in my situation?

1
macoscocoaplugins
A dialog isn't a child window. See Dialogs in the Human Interface Guidelines. Do you want to show a sheet, a modal dialog or an alert? – Willeke
Thanks @Willeke; an app-modal dialog is what I'm after here; I'm being called from the host app's GUI thread and it should be unresponsive while my dialog is up (it expects this at this point). So I think I shouldn't use sheets, seeing them mentioned for document-model dialogs? Using the addChildWindow function does make my dialog a modal dialog wrt the parent, if only for it's menu still being active and responsive, so there's prob. a better way to handle this on OSX :) – Carl Colijn
Possible duplicate of How do I create a custom modal NSWindow? – Willeke
@Willeke: indeed seems like it is. I've tried the technique described there [[NSApplication sharedApplication] runModalForWindow: myDialogWindow] , but it only leads to lockups... Furthermore, I'm using a GUI framework (Juce) for the windowing, and it in turn already does it's own modal loop (a CFRunLoop -- sp?) and handling Cocoa messages, so I guess it is incompatible with calls to runModalForWindow which blocks on the spot. – Carl Colijn
That said I only need the host's menu to become disabled/hidden/replaced-by-mine/whatever, but I guess accessing [[NSApplication sharedApplication] mainMenu] and tweaking that is Truly Evil? I saw menus are disabled automatically by unassigning handlers to items, so I'd have to loop over all menu items and assign nil handlers to them, later restoring them -- seems like quite a dirty hack, if it even works that is. – Carl Colijn

1 Answers

0
votes

When chasing another idea I stumbled upon Cocoa's [NSApp beginModalSessionForWindow] in combination with [NSApp runModalSession] and [NSApp endModalSession]. This is meant for running a particular window in a parallel modal session while still doing some processing yourself (you're supposed to call runModalSession in a loop).

However, since my code is structured like:

  1. let the cross-platform GUI framework create our NSWindow
  2. attach this NSWindow to the host window as a child window
  3. let the cross-platform GUI framework run the window's modal loop
  4. detach our window from the host window
  5. profit

I could easily sneak in a

NSModalSession session = [NSApp beginModalSessionForWindow:ourWindow];
[NSApp runModalSession:session];

between 2 and 3 above, and add the closing

[NSApp endModalSession:session];

between 3 and 4.

Since beginModalSessionForWindow doesn't block on the spot like runModalForWindow does, the GUI framework's modal loop can still be ran, but it does have the effect that the host's menu is now unresponsive. Not disabled / greyed out, but unresponsive is good enough for me right now.

However: since I'm far from an experienced OSX developer, I wonder if I introduced any nastyness by doing it this way?