I've been keeping in mind the advice from other threads about trying to avoid code called within #if JUCE_MODAL_LOOPS_PERMITTED blocks.
Whilst trying to decide whether to bend FileBasedDocument to my current task or just write something specialised, I noticed that most of it is in fact dependent upon this. I couldn't see any ready-made alternative, so I found myself wondering if maybe I'm missing something (since you recommend disabling modal loops, yet FileBasedDocument is used in Introjucer).
I figured I'd try actually disabling it myself (i.e. setting JUCE_MODAL_LOOPS_PERMITTED=0). However, I don't even seem to be able to compile a basic app [NOTE: only tried on windows so far] with this disabled - JUCEApplicationBase::main/quit both call functions in MessageManager that aren't defined without it.
Am I missing something? Should it actually work with this disabled, or is this something that actually isn't really ready to do on all platforms?
It's probably just baby-brain rendering me incapable of seeing something obvious!
Yeah, that's a tricky one because it relies heavily on platform native file-choosers which are modal. (And to be honest, it'd be a bugger to refactor it to work asynchronously!)
Since it's a class that's probably only relevant for apps in desktop-OSes, I've not bothered too much about trying to sort it out, but at some point it'd be nice to get everything in the library to be async.
Would you also be able to clarify if should actually be possible to compile an app on windows with JUCE_MODAL_LOOPS_PERMITTED=0? I'm not sure if I've done something wrong on my end, but (as mentioned above) it seems there are some calls in JUCEApplicationBase::main/quit that don't have definitions (i.e. MessageManager::getInstance()->runDispatchLoop() and MessageManager::getInstance()->stopDispatchLoop()).
Perhaps they're defined somewhere else and I'm just not setting the flag in the right place to get them included in my code!
