Window/Combobox invisibility bug is related to Kontakt5 and getStateInformation()


#1

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.

 very weird. 


#2

Maybe the whole app is hidden?


#3

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.

 

Flumm-oxed I am. 

 

 


#4

Apps can be hidden. Like when you press Apple-H.


#5

to clarify - the title bar goes white ie the window has lost focus.  The main app window stays visible.  

AND the app menu bar  stays in place. 


#6

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. 


#7

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?


#8

there really isnt any of MY code that is doing any painting. 

 

in one situation its just an audiounit ( Kontakt, Ivory, BFD etc ) window being opened and displayed inside a "shell" window 

in the other its a combobox that refuses to show its  popupmenu ( dropdown ) window with just a list of numerical choices: 1,2,3,4,5

But - NOTE: - when the app is in a "mode" where everything goes wrong - ALL my Comboboxes refuse to open their drop-downs. 

There isnt in fact ANY window being drawn white - drawn "invisible" ( or with alpha = 0 ? ) would be more accurate. 

 

And theres this weird thing that if i open a simple native OSX dialog box - suddenly by magic my AU plugin editor appears where it should. 

 


#9

NOTE: - when app is in a mode where everything goes wrong - ALL my Comboboxes refuse to open their drop-downs. 

Note also that there is a mode when EVERYTHING displays as it should.  Its just under some mysterious circumstance - series of

events - in which the weirdness happens


#10

Have you tried forcing a repaint on the window?

Rail


#11

i'll give it a go -on the AU window, on my MAIN window - and hmmm - on the combobox dropdown ... somehow


#12

Yes - i have a test button now  which can force a repaint() on the AudioProcessorEditor instance

but it made no difference. Still didnt display -  UNTIL  i clicked another test button which displays a simple modal dialog. 

 

THEN the AU editor appears !

 

 


#13

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. 

 


#14

Hi nonchai,

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.


#15

Just a thought but are you calling get/set StateInformation on a background thread?


#16

No.  

 

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. 


#17

Hi Jules, Timur, Fabian

 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

inside xcode. 


#18

Hi Timur n all - any nearer to solving or looking at this ? 


#19

I've sent you a message...