Site navigation

Modal dialogs

Audio Plugins
#1

 

Hey Jules - 

I'm Just wondering about the state of things like fileChoosers and menus inside plugins.  I am aware, of course, that modal dialogs are problematic in plugins.  

However, I currently use both PopupMenus and file choosers in several VSTs, and have yet to see any real problems.  Still, it might be that the hosts I'm using are fine, but it breaks in others .... not sure.  Or maybe you have tweaked the code and they are not problems anymore?

 

Also - I assume that secondary windows inside plugins are fine (just that modal ones are not).  So ... why not just have filechoosers and PopupMenus come up a full second, non-modal windows?  This would be great for Android too, of course, since modal windows are no good there.

 

 

Anyway, just wondering.  I realized a few weeks ago that I have a few modal dialogs in my plugs (that seem fine) ... but maybe I should switch them out, huh?

 

Also - wasn't there a flag for disabling modal loops altogether?  If so, why not set that for plugins and disallow users from even trying modal dialogs?

 

Thanks~

 

 

 

 

#2

File choosers are a bit tricky because on e.g. win32 the OS calls that run them are actually modal, so restructuring the classes to work asynchronously could be interesting. Good points though, thinking a bit more about this is all on my to-do-list.

Re: just putting in a hard disabling of modal loops in plugins is a good idea, but would probably break a lot of people's code! I would recommend setting that flag (JUCE_MODAL_LOOPS_PERMITTED=0) in your plugins if you can though.

#3

 

Yeah, it would be amazing if non-modal versions jut came up automatically when modals were not appropraite.  Thanks for looking.  

What about the PopupMenus?  Are those safe to use in plugins?  They seem to be .... but maybe I'm just using a forgiving configuration?

I'm using show(), but I guess if there are issues, perhaps I should use showMenuAsync() ?

 

#4

If you use async PopupMenus, then yes, that should be safe enough.

#5

 

Ah yes, so definitely switch them out to showMenuAsync().  Cool, thanks.

#6

 

So I just got some error reports from users, and tracking the problem down realized it's because labels also enter a modal state when being edited.

 

Any simple way around that one?

It's probably not too hard to implement a non-modal label editor.

 

 

 

#7

Entering a modal state is ok. It's when you try to run a modal loop that bad things start to happen!

#8

Ah, of course.

Hmmm .... that leaves me a little lost then.  About 5% of my windows users report than they can't click inside the textboxes (labels) at all.  

From what I can gather, it seems to be a windows vista/XP thing ... not win7/8.  They click on the label, but it never lets them edit the value.

I'll keep pushing them for info, since I can't replicate it either.