# JUCE\_MODAL\_LOOPS\_PERMITTED questions **URL:** \ **Category:** General JUCE discussion\ **Created:** [February 21, 2014, 3:54pm UTC](https://forum.juce.com/t/juce-modal-loops-permitted-questions/12422 "2014-02-21T15:54:20Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![haydxn](https://avatars.discourse-cdn.com/v4/letter/h/5fc32e/32.png) [@haydxn](https://forum.juce.com/u/haydxn)\ **Post date:** [February 21, 2014, 3:54pm UTC](https://forum.juce.com/t/juce-modal-loops-permitted-questions/12422/1 "2014-02-21T15:54:20Z")
Hello! 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! ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [February 21, 2014, 3:57pm UTC](https://forum.juce.com/t/juce-modal-loops-permitted-questions/12422/2 "2014-02-21T15:57:38Z")
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. ---
**Author:** ![haydxn](https://avatars.discourse-cdn.com/v4/letter/h/5fc32e/32.png) [@haydxn](https://forum.juce.com/u/haydxn)\ **Post date:** [February 21, 2014, 4:09pm UTC](https://forum.juce.com/t/juce-modal-loops-permitted-questions/12422/3 "2014-02-21T16:09:18Z")
Glad I'm not going mad there then :) 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! ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [February 21, 2014, 4:12pm UTC](https://forum.juce.com/t/juce-modal-loops-permitted-questions/12422/4 "2014-02-21T16:12:05Z")
TBH I've not tried compiling on Windows with that flag.. It could easily be the case that something would need tweaking.