Thanks for your support in advance.
We are exploring JUCE Framework and it’s usage for developing plugin’s…etc
We have developed sample plugin’s using JUCE Framework.
JUCE claims that same source code developed on one platform can be ported onto other platforms without any changes.
Hence we have ported plugin developed for windows platform onto Android platform.
But we have end up with build errors w.r.t functions supported
under “ JUCE_MODAL_LOOPS_PERMITTED == 1”.
Note: For Android platform, this macro “JUCE_MODAL_LOOPS_PERMITTED == 0”.
Android platform build errors for below discussed functions:
’juce::FileChooser::browseForFileToOpen() & juce::FileChooser::browseForFileToSave()’
By referring to below link we understood that this is due to Android compatible issues.
Build errors for Android not seen in win/osx/iOS - Android - JUCE
Kindly support us to resolve the above errors on Android platform without doing any code modifications.
Hi, you’re going to need to change code I’m afraid. I know this is frustrating as I went through the same process a few years ago.
Android doesn’t allow modal loops so everything has to be done via async launching of dialogs which can be launched sync on other platforms.
I guess that the claim is correct if you happened to write everything async in the first place, but if you didn’t then changes will need to be made.
@leehu covered all the important points. Modal loops are completely unsupported on Android, so code that uses modal loops cannot be ported. Code that was written with modal loops disabled from the outset should be portable with no additional changes.
For the most part, modal functions have asynchronous equivalents, and it should be reasonably straightforward to convert modal code to be asynchronous.
In a future release of JUCE, we are planning to set
JUCE_MODAL_LOOPS_PERMITTED to zero on all platforms by default, which should make it easier to write completely portable code. Of course, it will still be possible to enable modal loops on platforms that support this feature, for backwards compatibility.
Hi. I presume this has been done now as I have some compilation issues with latest pull.
Is there any help on how to rewrite our existing code, e.g.
juce::CallOutBox callOut (colourSelector, getScreenBounds(), nullptr);
value = colourSelector.getCurrentColour();
Yes, this change is mentioned in the BREAKING CHANGES doc in the repository.
hi - thx. yes, have seen that. sorry, some of the text got missed form my last post as I wondered if there are any hints anywhere as to how to rewrite existing code, such as the bit I provided, without using modal loops?
The example projects (e.g. the WidgetsDemo) shows how to use
CallOutBox::launchAsynchronously, and the class docs for CallOutBox has a code snippet showing how this function can be used.
@tpoole updated all of the demo projects to avoid modal loops, so those are probably a good place to start if you’re unsure how to rewrite usages of modal functions.
Just realised it’s gin code. Will see if that’s been updated yet - will have to reenable the flag until then.
@reFX hi - are there any plans to update the gin library so it builds without the JUCE_MODAL_LOOPS_PERMITTED flag set to 1? thx
That’s more a job for
@FigBug, since he wrote Gin. I assume that this will happen rather sooner than later. We are using Gin, but mainly for the Image functions and some odds and ends.
ah, thx. Mainly image functions for me also.
Which function is giving you the compiler error?
Theres a couple of calls to FileChooser::browseForDirectory() and a call to PopupMenu::show().
I can’t find any instances of PopupMenu::show in Gin. They all using ::showMenuAsync
Gin doesn’t have a call to that.
I may have an old repo - will refresh it. thx
Hi - that was it, I had an old repo. thx.