I note AudioProcessorEditor inherits from Component, and there’s a separate class called ResizebleWindow?
I actually already have all my components auto-positioning and resizing to meet whatever window size I through at it. I’ve tried calling setResizable( true, true ) and have a resizing corner graphic but can’t actually change the size.
(BTW Visual Studio 2017 C++, Window 7/32-bit, I know a rare combination but MIDI in and Audio out work perfectly in stand-alone mode.)
The AudioProcessorEditor is wrapped into the host’s plugin window. THerefore you cannot use the ResizeableWindow.
But AudioProcessorEditor has a setResizeable() method that you already found.
There is a caveat, if you already called setSize() I think the setResizeable() won’t work any more.
The setSize() in the constructor should happen at the end if you read the comment, but it’s a bit cryptic, so most people fall in that trap once.
I believe you also need to setResizeLimits() otherwise the window will still be fixed size. Maybe it’s changed but I seem to remember that being a requirement.
That’s actually what worked for me.
However you should be aware that there might be some issues with VST3 in some hosts like Ableton if you do it like this, there’s a separate thread about this.
Calling setResizable() first, THEN setSize(), results in the resize handle lower-right-hand corner actually resizing the window. I had setSize() first and got the resize handle but it couldn’t do anything.
OK, so setSize() in your constructor calls resized() so you have to be ready to handle that: don’t setSize() your original size until enough has been initialized that resized() will work…
Next trick: In resized() I take the new height and width, come up with the best layout I can, and if that is not the current height and width, then I just setSize() (and then return, as setSize() will have called me again!).
Example: I am 200x100 and must be twice the width as height, and I can only increase width by 10 pixel increments. I find the user has tried to resize me to 209x150. That’s not quite wide enough to increase, so I setSize() to 200x100 and in practice stay the same. Then the mouse moves one more pixel right, and now the attempt is 210x150. I can resize to 210x105 and do so. It sounds really hacky, but in practice it works just like you’d want it to. It’s not at all confusing, or flickery, or anything.
void Tutorial2AudioProcessorEditor::resized() {
int iWidth = getWidth(), iHeight = getHeight();
dPixelPerUnit = blah blah; // say my GUI is layed out as if it were on a 16x12 grid and this is the size of one box on the grid
// If we let this go to zero, Juce has an assertion failure. But should we have a
// min that merely avoids crash, or one that gives some sense of the appearance?
if ( dPixelPerUnit < 10 )
dPixelPerUnit = 10;
int iWidthIdeal = int( dPixelPerUnit * dXMax ), iHeightIdeal = int( dPixelPerUnit * dYMax );
// We can reduce our size to eliminate wasted space, without moving the mouse, and thus
// get smooth live resizing. Even as the user tries to enlarge us, we may keep shrinking back,
// but once the mouse cursor gets to a bigger size that fits our constraints, we use that size.
if ( iWidth != iWidthIdeal || iHeight != iHeightIdeal ) {
setSize( iWidthIdeal, iHeightIdeal );
return;
}
