# \[Bug\] In JUCE 9 APH, can't change plugin window size procedurally unless setResizable is true **URL:** \ **Category:** Audio Plugins\ **Created:** [November 10, 2026, 10:49pm UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882 "2026-11-10T22:49:03Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 10, 2026, 10:49pm UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882/1 "2026-11-10T22:49:04Z")
(testing on MacOS) (EDITED: this is a problem with the AudioPluginHost only it seems, read farther down for the exact commits that introduced the issue.) I have a scaleFactor menu setting in my plugin, i.e. 100%, 150%, 200% (1.0f, 1.5f, 2.0f). Since updating to JUCE 9.0.5 (from JUCE 8.x), and rebuilding the AudioPluginHost, changing the scaleFactor on the plugin no longer resizes the plugin window - it only changes the zoom on the content. What has changed on the scaling side? The way I do scaling is I have my MainComponent inside a Wrapper (which is the AudioProcessorEditor). The MainComponent gets a Transform set on it to change the scale, while the AudioProcessorEditor’s size is changed.. In the past, this would automatically resize the plugin window, worked flawlessly, but it doesn’t anymore. ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 10, 2026, 11:38pm UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882/2 "2026-11-10T23:38:34Z")
That’s weird. It starts working again if I call `AudioProcessorEditor::setResizable(true, false)`. I have never had to set my plugin to be resizable before. I just want to choose from one of several preset scaling factors - which always worked before. I don’t want the user to be able to resize it by dragging, but now you can drag the corner and sides, which doesn’t scale my content but just reveals black empty space. How do I get around this? ---
**Author:** ![zsliu98](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/zsliu98/32/22502_2.png) [@zsliu98](https://forum.juce.com/u/zsliu98)\ **Post date:** [November 11, 2026, 1:14am UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882/3 "2026-11-11T01:14:22Z")
Perhaps you can do something with `this->resizableCorner` of the editor? I have fully customized the re-sizing corner in plugins in such way. I would guess you could hide it & let it ignore mouse event similarly. ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 11, 2026, 1:17am UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882/4 "2026-11-11T01:17:36Z")
the resizable corner is already hidden when you specify false for the second arg of setResizable(). But you still get the resizing arrows when you hold the mouse above the edges or the corner. I want to set the size procedurally like I always have, while not allowing any hint of being able to drag the edges. I’d like to confirm from the team that this is some sort of change in JUCE 9? @reuk @anthony-nicholls ---
**Author:** ![zsliu98](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/zsliu98/32/22502_2.png) [@zsliu98](https://forum.juce.com/u/zsliu98)\ **Post date:** [November 11, 2026, 1:25am UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882/5 "2026-11-11T01:25:06Z")
Sorry, I mean you specify the second arg of `setResizable()` as true and delibrately hide the corner by `setVisible(false)`. I have just tried this and the resizing arrows do not appear, as expect. I would agree that it is only a temp workaround. ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 11, 2026, 1:27am UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882/6 "2026-11-11T01:27:35Z")
the resizing arrows appear whether the corner is visible or not. This is an OS thing. Even away from the corner. Hold the mouse over the right edge, you get a horizontal arrow. Hold the mouse over the bottom edge, you get a vertical arrow. ---
**Author:** ![zsliu98](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/zsliu98/32/22502_2.png) [@zsliu98](https://forum.juce.com/u/zsliu98)\ **Post date:** [November 11, 2026, 1:30am UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882/7 "2026-11-11T01:30:09Z")
I don’t think so and I cannot re-produce that. That would only happen if you pass the second argument as `false` and JUCE would | **useBottomRightCornerResizer** | if true, it’ll add a **[ResizableCornerComponent](https://docs.juce.com/master/classjuce_1_1ResizableCornerComponent.html "A component that resizes a parent component when dragged.")** at the bottom-right; if false, it’ll use a **[ResizableBorderComponent](https://docs.juce.com/master/classjuce_1_1ResizableBorderComponent.html "A component that resizes its parent component when dragged.")** around the edge | | --- | --- | ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 11, 2026, 1:45am UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882/8 "2026-11-11T01:45:03Z")
Oh! It sounds like you may be right, my apologies. I assumed it was an OS thing. I will check it out and let you know. ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 11, 2026, 2:39am UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882/9 "2026-11-11T02:39:34Z")
Getting back to the original issue for a moment: This appears to be an issue with the JUCE AudioPluginHost (only?) I just tested my plugins on Reaper (Mac) and they work normally. You can change the scaleFactor programmatically without calling setResizable(true). It seems to be a change to the AudioPluginHost. EDIT: could it be this commit? > ---
**Author:** ![stephenk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/stephenk/32/15198_2.png) [@stephenk](https://forum.juce.com/u/stephenk)\ **Post date:** [November 11, 2026, 9:24pm UTC](https://forum.juce.com/t/bug-in-juce-9-aph-cant-change-plugin-window-size-procedurally-unless-setresizable-is-true/69882/10 "2026-11-11T21:24:03Z")
Yes, the above commit is indeed the culprit. Secondly, for VST3 plugins only, there is an additional commit that is part of the problem. With the above commit removed, resizing procedurally works on the content, but the plugin window does not change to the correct size until you move it 1 pixel or so: > > > This fixes an issue where size constraints would be reported incorrectly > for VST…3 editors that have a single supported size, and that fail to > return that size from checkSizeConstraint. An example of such behaviour > can be found in the UA DSP plugins 11.9.0. I am removing both these commits from my AudioPluginHost until I can get some response from the team @reuk. But to paraphrase Obi-Wan Kenobi, “These aren’t the fixes you are looking for.”