RTAS upper window sometimes not drawing

There is a part of the RTAS plugin that is drawn–insofar as I can tell–by ProTools. This is the upper section that hold bypass, preset load, etc. In builds of the last couple of weeks, I’ve observed that area sometimes not being drawn: there’s just a white rectangle. Click around a while and it usually appears. It would seem to me this is in the domain of ProTools and not my plugin, but it does not happen with versions of Juce going back a few weeks. The version of ProTools hasn’t changed in months.

Is there something I should be doing, or is there perhaps some sort of flag in the RTAS wrapper that might be in an undetermined state? I don’t know that it’s Juce’s fault, but I don’t know what else it might be related to. Anybody see this?

Noticed this too since RTAS: changed OSX Carbon window class. on OSX 10.8.2


[quote=“Rail Jon Rogut”]Noticed this too since RTAS: changed OSX Carbon window class. on OSX 10.8.2


It was a change suggested here: http://rawmaterialsoftware.com/viewtopic.php?f=4&t=8807

That seems to be a response to a legitimate issue (of course some people never seem to quite ProTools), but it does have this side effect. I didn’t catch it until I put a version out the other day. Of course a couple of customers caught it. It’s probably harmless, but it scares the pants off 'em. Is there a more effective solution?

No time to investigate, but if anyone has any better ideas, let me know!

Well I can confirm that commenting out the new line 55 fixes the problem… with the change the OSX close button is also not being drawn correctly BTW…

BTW - Line 69

NSRect hostWindowScreenFrame = [[hostWindow screen] frame];

generates a warning: Unused variable ‘hostWindowScreenFrame’


Ok, I’ll revert that change, and add a note about why.

I’ll see if I can figure something out as well…



Thanks Jules. RTAS can’t go away fast enough, but it sure is fighting back as it goes down.

Just found a nasty side effect with RTAS and having JucePlugin_EditorRequiresKeyboardFocus set to 1…

If you run the JUCE plugin demo you can recreate the issue… which is an unusual/edge case, but could happen…

Instantiate the JUCE demo RTAS plugin, close the Mix and the Edit Windows… press any key… Pro Tools hangs and the function redirectKeyUp() in juce_mac_NSViewComponentPeer.mm is called endlessly…

In my tests, the change to add the

HIWindowChangeClass ((WindowRef) hostWindowRef, kFloatingWindowClass);

never made any difference on my system… keyDown() and hence redirectKeyDown() in juce_mac_NSViewComponentPeer.mm is never called for any keystrokes when there’s a menu option for the key combination…