Viewport draws contained AudioProcessorEditor outside of its bounds

General JUCE discussion
1

This is really a duplicate of a forum post from 2018:

https://forum.juce.com/t/expert-needed-why-is-it-not-possible-to-display-and-bound-an-audio-editor-instance-inside-a-viewport/26647

Since that thread never reached a satisfactory conclusion I’ll try asking again in a different way.

I have a Viewport that displays a stack of AudioProcessorEditor sub-components. The component hierarchy looks like this:

ViewPort
- viewedComponent
-- stack component 0 (Buttons, AudioProcessorEditor)
-- stack component 1 (Buttons, AudioProcessorEditor)
-- etc.

While each stack component – and the contained Buttons – are correctly clipped by the Viewport, the AudioProcessorEditor is not. It is drawn over the scrollbars and outside of the Viewport’s bounds.

normal
scrolled

In the screen shots you see how the AudioProcessorEditor (containing the text ‘Melody’) draws outside of the Viewport, while its Button sibling components behave as expected.

I’ve tried fiddling with the AudioProcessorEditor instances like this, but to no avail:

audioProcessorEditor->setPaintingIsUnclipped(false);
audioProcessorEditor->getPeer()->setAlwaysOnTop(false);

I’m quite new to JUCE, so I’m not sure how to continue from here.

BTW, all this happens on macOS, and the hosted plugin UIs are NSView based, but I’m not sure it’s a mac specific issue, which is why I’m posting in General Discussion.

Thanks for any pointers,
patrick

2

The hosted plugin is a native window. Have you ever seen any other DAW draw or scroll on top of it the way you’re trying to do it?

3

I don’t believe that is correct.

Granted, JUCE strangely doesn’t seem to have a proper window class, but

audioProcessorEditor->isOnDesktop()

returns false.

Also, after adding the loaded AudioProcessorEditor instance to my Viewport

audioProcessorEditor->getWindowHandle()

returns the exact same pointer as my own plugin’s window handle. There is no other window.

4

Sorry, I meant a native window handle and not a separate window. However I believe in terms of the OS it’s managed as if it’s a separate window in terms of drawing and event handling.

Have you ever seen another DAW that has that feature?

5

It’s important to mention that the editor you’re seeing in your code is not the actual editor. It’s a wrapper around the real editor - which I believe would have a separate handle than yours.

6

I don’t quite understand why it doesn’t work as advertised.

Plugins are just views, not windows. The ‘window’ is only supplied by the DAW.

Here I’m just loading (having JUCE load) a couple of plugins, and their AudioProcessorEditors. The DAW that my plugin is running in is not involved / aware.

Case in point: when I’m developing a native Cocoa application that loads Audio Units, I can access the NSView that the AU provides, stick those into an NSScrollView or NSCollectionView and do anything with it that an NSView supports.

Currently the loaded AudioProcessorEditor are clipped to my plugin window bounds, but not by the Viewport inside my plugin window.