is there something in the Cocoa/OSX API that can inhibit “opened” windows from showing until a later time ?
None of my plugin editor windows display when the relevant code is called - UNTIL if after this I call the native cocoa [alert ... ] code to display a modal alert box. Then as if by magic - the plugin editor window shows - eactly where and how it should do.
what do you mean ? if you mean something like using Process::setDocIconVisible(true) then no.
my main app window is visible. BUT ... interestingly the main window title bar goes white - indicating the main window has now lost focus.
But to what ? to the editor window which is invisible ?
plus theres this weird related thing of the combobox popup window not displayin either. even though far as i can tell the code executes exactly the same as when everything is working fine.
I also should clarify that this project - this window and the functionality to load plugins, show the plugin editors etc etc
has been workng fine as expected for a long time.
It seems that this problem has only occurred since I recently moved to the latest version of JUCE. Its all been going on around the same time that i moved from Mavericks and Xcode 5 to Yosemite and Xcode 6 in the last few months, but the functionality to load up plugins on launching the app and then open AU editors when requested - has all been in and the code unchanged for a very long time.
OSX has become more strict in recent version on how much time you are allowed to spend drawing on the message thread. If you take too long, OS X will just paint your window white. Try removing any code that might be taking a long time to paint and see if your app starts painting again. If yes, then you may have to move the painting to another thread and cache the result into an image object which you can then paint on the message thread. Does this make sense?
Turns out the Window issue seems to be related to Kontakt when loading previously saved MULTI data using AudioProcessor::getStateInformation().
I've isolated this down to just Kontakt. If I have my app load an instance of Kontakt but don't load any previously saved plugin state data, my windows and popups operate fine.
If I also call getStateInformation() to load the saved state - which in my case consists of MULTI data where during the loading process Kontakt displays some temporary windows briefly ( indicating its loading and converting nki instrument data ) it is I think this display of windows temporarily that puts the JUCE or OSX/Cocoa framework into this funny modal state.
I've also noticed that simply opening a modal non-native JUCE dialog once this happens - behaves as if we're on "modal" mode yet no window is shown. However the dialog window ( a custom one by me ) IS actually being instantiated and opened as it would.
This is very weird but needs sorting.
I am putting together a cut down test app to send to you to illustrate this bug.
I did check to download the latest version of Kontakt in case it was a known bug sorted now. But since i can open up K5 in multi output mode and load saved data in Ableton fine - this is something pertaining to JUCE and Kontakt interaction.
Yes, a cut down test app would be nice, because otherwise it's really difficult to tell what is going on... to be honest I have no idea. I have Kontakt 5 installed here, so I could maybe find some time to check it out.
But since Kontakt 5 runs internally in multithread whenever it wants - I suppose its possible that when its loading the preset internally for the Kontakt Multi that this could be a thread and K5 displays the temporary info ( loading bar ) windows in that thread.
But that would be pretty bad if NI are doing this - but it would make sense.
Far as my code is concerned - everything is happening in the JUCEApplication::initialise() method ie main message thread.
i've now sent a zip file of the cut down project to Jules via email.
It took me a long time to put this together so I’d appreciate if you/ “stick with it”.
Contact me via Skype if necessary and i can explain an help you sort out final “gremlin finger trouble issues”
theres a readme file in there but i think its best if we arrange a telephone call and/or Skype etc so i can talk you through it after you've built the app successfully