Dialogs on plugins, modal, non modal


#1

I need some yes/no type alerts in my plugin. I've had several attempts at this and keep running into, to my opinion, silly problems. I've been reading the forum and have really gotten nowhere.

My fisrt attempt was to simply popup a modal alert window synchronously (my use of terminology may be incorrect so please bare with me), but i'm unable to destroy the window if the host quits while it is visible. So, after reading a bit, i learnt that modal inline dialogs are a no no anyways. I have yet to learn why, but i take it is so, since using asynchronous dialogs with callbacks was the only answer i found to the problem.

My second attempt was to use asynchronous alert window with a callback. This introduced the problem of the alert window, which is blocking input to the plugin, as it is supposed to, possibly getting behind the plugin window, and most likely getting completely obscured by it. So the buttons to close the alert that is blocking the plugin is behind the plugin! As a user, i've found this to be one of the worst UI glitches i've ever witnessed. And... i can't close this alert window, when the host quits, any better than the inline alert window.

So i wonder. If i need to show the user a couple of lines of text and yes/no buttons, is it worth all this trouble? Why don't i just add a regular component - a fake dialog window - over my plugin's UI, disable all other components, and wait for the user to choose yes or no, after which i hide the "dialog" and handle the user input? Can you talk me out of it? My point is not to give you a rant about dialogs, but to illustrate my current state of understanding on the whole subject, which may not be much.

What do i need these alert windows and the like that Juce offers for?

And what am i missing when i think the problem doesn't deserve this complicated solution?


#2

You shouldn't use AlertWindows or Child modal dialogs in plugins.. they have the potential to be displayed in the wrong Z-Order and can end up behind another window in the DAW which will cause the user to be completely locked out.. just getting a "Ding" from the system speaker and eventually causing them to have to force quit the host and lose any unsaved work.

 

Rather create a Component class which covers the whole plugin and display the text, etc there.. then hide or destroy the component after using it.

 

Rail


#3

Yes, that's what i was thinking, except that your suggestion is even better, saving the trouble of tampering with the main UI's components. And thank you for explaining the problem. Although, IIRC, i've been lucky enough to never actually seen that happen, your answer makes perfect sense to me. Thank you very much Rail!

Matti