… then I set the PluginEditor’s size later in the constructor, then somehow the parent of the editor will get an x;y offset of a few pixels leaving unoccupied space in the top and left of the Editor.
It seems reSetting the size of the Editor later, whenever it is already added to a parent will realign the positions and removes the gaps… Obviously setting the size again wouldn’t do the trick so setting it to 0;0 then set it to the original size will fix the alignment (but not in the constructor as then it doesn’t have a parent yet).
It seems not every scalefactor causes this, so maybe it’s some kind of rounding problem:
I can’t repro this if the scalefactor is <= 1.0f
depending on the actual size of the plugin some scale factors introduce the offset, some not.
I just creted a brand new JUCE project and did nothing but added the next line before the setSize(400,400):
Not that this shouldn’t work as described, but the way I’ve always done this is activate the resizer, wrap your editor all in a single “MainView” component or whatever, and apply a transform to that when size changes.
Yeah, as far as I remember that was the classic way to do it, but now JUCE recommends to use the GlobalScaleFactor… I could be wrong though. And yes the transform probably can cover this issue as a workaround, just wanted to know if it’s me doing something silly or not.
Thanks for reporting. The issue was a bit deeper than a rounding error, but the rounding error was flagging up the root cause. With certain global scale factors the integer top-left position for the plug-in window was changing slightly, causing the SWP_NOMOVE flag to be unset it the call to SetWindowPos. This exposed a problem with how we were calculating the client coordinates for HWNDs with a parent which has been addressed in b5a06b0. I’ve tested this in Live 10 and 11 as well as a few other hosts and it seems to fix the issue but please let us know if it hasn’t fixed things for you.
