Showing dialog modal and specifying host parent window

#1

Hi all,

I’m trying to have my Windows + OSX plugin show a dialog modally wrt the host app, but am having a hard time doing so.

And before everyone jumps at my throat: yes, ‘modal is bad’, but my host (Premiere) just wants a modal dialog from it’s plugins. I basically have a “Show your dialog” C callback function the host calls, and when I return from it, the host requires the dialog to be closed again. It really just expects you to do a MessageBox etc., but I want something more fancy ofc. Therefore ‘modal is bad’ doesn’t apply here and modal(-like) really is the better/easier way to go.

Right now I am using DialogWindow::LaunchOptions, filling it in, calling it’s launchAsync(), followed by it’s runModalLoop(). This almost works, but since I don’t set the parent window, I can still alt-tab to the host again and I’m left with an unresponsive fullscreen host. Just clicking it makes my dialog show itself on top again, but it’s not ideal.

I do have the native window handle of the host app, but I don’t see a way to have my juce DialogWindow/TopLevelWindow use it. There is the addToDesktop() method, but I can’t seem to make it play nice with DialogWindow::LaunchOptions.launchAsync() nor DialogWindow.enterModalState().

All help appreciated!

0 Likes

#3

If I understood the original poster correctly, this is some special case where the host itself asks the plugin to show a modal dialog. Obviously it will be very hard to give any specific advice since few people here (probably no-one) will know anything about Premiere specific callbacks. (Is this even about a VST plugin, I wonder…?)

0 Likes

#4

No, it’s not VST plugin in any way indeed. It’s a video transition/effect plugin for Adobe Premiere.

The host (Premiere) just has a “settings” button of sorts in it’s interface which (when pressed) calls my callback function in a blocking way. So, when called, my function must show a modal dialog; the host isn’t expecting anything else. Once I return to the host, the host unblocks itself again, so I shouldn’t return while the dialog is still up (= exit message loop for the dialog; I have to run my own message loop as well). The routine also (indirectly) gets passed the host’s window handle which I can use to parent my dialogs to.

So there’s also no permanent screen real estate which shows my own interface, which I could place an async full-size (thus blocking) component on top of to simulate modality (which seems to be the case for the typical plugin developers here?)

So, again, I know ‘modal is bad’ :slight_smile: but in my case it doesn’t apply and I actually really need it. In that regard my plugin really is more like a normal console app than a VST plugin.

0 Likes