Bug: resized call with wrong bounds on init

Hey, I’m on windows and currently on the JUCE commit ae2378e from 13th july.
In my current project I have these lines in the editor’s constructor:

const auto& user = *audioProcessor.state.props.getUserSettings();
const auto editorWidth = user.getIntValue("EditorWidth", EditorWidth);
const auto editorHeight = user.getIntValue("EditorHeight", EditorHeight);
setOpaque(true);
setResizable(true, true);
setSize(editorWidth, editorHeight);

And these in resized:

auto& user = *audioProcessor.state.props.getUserSettings();
const auto editorWidth = getWidth();
const auto editorHeight = getHeight();
user.setValue("EditorWidth", editorWidth);
user.setValue("EditorHeight", editorHeight);

I am saving and loading width and height values in the xml file of the ApplicationProperties so that the plugin remembers its desired bounds for all instances to come.

But lately I noticed that my plugin keeps shrinking the more I reopen the interface and I was wondering why, so I put breakpoints into the constructor and resized and noticed something strange happening. Every time I load up the plugin it calls resized twice, but the 2nd time it is called, both getWidth() and getHeight() return their values minus exactly 6 pixels. That’s why the plugin is getting smaller and smaller. Unfortunately I can not figure out why this is happening, because the callstack goes back into some lowlevel JUCE code.


The only thing I was able to find out was that somewhere in the callstack this bool called “wasMoved” was true, triggering all this stuff. But why was it true? I didn’t use code to move the interface and also didn’t affineTransform it or anything

Is this in a standalone plugin? If not, in what host and plugin format do you see this issue?

this is exclusively happening with the standalone build of the plugin project

Have a look at the example code for this tutorial:

(resizable-plugin-window-demo/Source/RasterEditor.cpp at master · Thrifleganger/resizable-plugin-window-demo · GitHub)

This method is a bit different to yours, but works perfectly across vst3, standalone and AU for me. Width and Height are static cast to integers which seems to hold a stable value.

Well, the method that I use also works perfectly, at least in older JUCE commits. From what we know so far the problem comes more from the standalone wrapper than my code

I’ve just rebuilt mine on the latest commit, windows .exe is fine.

No doubt it’s a recent change in the wrapper, I was just suggesting it might be a conversion error between those set and get methods to loose 6px every time like that.

Thanks for reporting this issue. Though this issue is present in 8.0.1, I believe that this is already fixed on develop, where we’ve made some significant changes to the way that window borders and resizing are handled. In short, the issue is caused by the top level window being created initially as a non-resizable window, then recreated as a resizable window with additional insets for the resizing border.

The following change should help avoid the situation where the top level window is recreated unnecessarily:

2 Likes

awesome! thank you so much :slight_smile: