(SOLVED) Can anyone confirm this issue in Windows 10 20H2? (VSTGUI)

[EvilDragon]

It seems like on Windows 10, 20H2, creating a COptionMenu that uses multiple columns and has submenus is rendered broken:



I unfortunately cannot find any other program that I own, that uses raw Windows APIs for drawing (i.e. not a framework like VSTGUI or JUCE), has multi-column menu with submenus to see if it's really a MS issue or a VSTGUI issue...

Just FYI, Surge Synth Team did fork VSTGUI in Jan 2019 at commit 37af1b00. That fork (with a number of our own fixes to VSTGUI) is available here.


We're about a month away from releasing 1.9, I would personally like to know if it's a MS thing or not so that we can then either axe the multi-column menu in this particular instance. Interestingly, a COptionMenu that doesn't have submenus works just fine!

Also, this only happens on Windows because VSTGUI implements multi-column menus only for Windows.


Thanks to anyone willing to answer!

[EvilDragon]

Hmmm, just discovered that Serum also has this multi-column menu with submenus for their preset menu, and that works fine in 20H2... and is also VSTGUI... Darn it!

[S0lo]

I'm under the impression that Serum is VST2, hence it's probably also using VSTGUI 3 (not VSTGUI 4). So if that works fine, then the issue could be with VSTGUI 4

[EvilDragon]

Good point there! Although IIRC Steve is working on VST3 version too, so... who knows?

But the main thing here is: the multi-column menu renders fine on all Windows versions PRIOR to 20H2... I can't see anything suspicious in here.

[mystran]

Nvm, didn't register the other check, ignore this.

[lkjb]

I had the impression IPlug also uses plain Windows menus which for example QRange uses for its settings. I haven't been pushed to 20H2 yet so can't say whether this is a problem in QRange/IPlug, too. I also might be wrong regarding the implementation in IPlug.

I think I'd build a simple VSTGUI plugin with only a COptionMenu and compile it using different VSTGUI versions to narrow down the culprit.

[EvilDragon]

Hrmmm...

https://github.com/steinbergmedia/vstgu ... onmenu.cpp

History of win32optionmenu. Unsure if anything here would be the cause. Unless this repo only contains VSTGUI 4. When was VSTGUI 3.6 released?

[lkjb]

Are you sure this is a Windows 10 20H2 issue? After compiling the github code and running the plugin (debug & release, current Reaper x64) in a Windows 10 Home 20H2 (build 19042.867) VM the menus were shown as expected.

Is there a reason for the airwindows plugins being included in the solution? At least a quick search didn't reveal any usage.

[baconpaul]

Are you sure this is a Windows 10 20H2 issue? After compiling the github code and running the plugin (debug & release, current Reaper x64) in a Windows 10 Home 20H2 (build 19042.867) VM the menus were shown as expected.

We made it off-by-default at head to avoid the bug. If you go to the workflow menu you can toggle it back on and then it will probably break (it does in our 20H2 tests)

Is there a reason for the airwindows plugins being included in the solution? At least a quick search didn't reveal any usage.

They are used to put the airwindows into the FX bank. The usage is in src/common/dsp/effects/airwindows and all of them are linked.

[lkjb]

If I enable "Use multiple Columns in Patch Browser Menu" I see the same horizontal menu with Windows 2004 Pro (build 19041.867) as I see with Windows 20H2 Home which looks quite like the screenshot above. Also, a quick test in a Windows 7 VM shows the same menu, maybe I misunderstand the issue.

[baconpaul]

If I enable "Use multiple Columns in Patch Browser Menu" I see the same horizontal menu with Windows 2004 Pro (build 19041.867) as I see with Windows 20H2 Home which looks quite like the screenshot above. Also, a quick test in a Windows 7 VM shows the same menu, maybe I misunderstand the issue.

Well that's good information. It means the bug isn't because of 20H2 but is because of "something else" which impacts some of our users. For the users not impacted, the experience with that menu swapped is way better, but of course, we can't make that a default for the reason you shared.

I wonder what it is if not the OS version! (I'm on MacOS so am not an expert in the vagaries of different windowses).

[EvilDragon]

This is weird because it works on my 2004 desktop (19041.867) just fine! Unsure if monitor matters, but 1920x1200, no OS scaling... using iGPU on my i7-6700K for graphics.

[S0lo]

I can't see anything suspicious in here.

In this, there is the lines:

Code: Select all

if (nbEntries < 160 && _menu->getNbItemsPerColumn () > 0 && inc && !(inc % _menu->getNbItemsPerColumn ()))
flags |= MF_MENUBARBREAK;

I'd try to debug here and see if flags variable gets the MF_MENUBARBREAK flag each and every time. If thats so then there is a lead here. It looks like it shouldn't get the MENU BAR BREAK until once in while. (i.e when inc is a multiple of getNbItemsPerColumn())

[EvilDragon]

Yep, it does...

https://imgur.com/aXyI9NQ

But only on my Surface, my desktop it's A-OK...


That's even with modifying the code to be:

Code: Select all

if (nbEntries < 160 && _menu->getNbItemsPerColumn () > 0 && inc && !(inc % _menu->getNbItemsPerColumn ()))
{
	printf ("Got menu column break at %d (pointer %p)!\n", inc, _menu);
	flags |= MF_MENUBARBREAK;
}
else
{
	flags &= ~MF_MENUBARBREAK;
}

[lkjb]

In CPatchBrowser.cpp, line 171, the following code sets contextMenu->nbItemsPerColumn to one as usercat_pos is zero.

Code: Select all

if (multicolmenu)
{
  contextMenu->setNbItemsPerColumn(usercat_pos - 1 + 2);
}

If I hardcode setNbItemsPerColumn(10) at this point the menu shows 10 items per column but the "Load from Patch..." part is making the other colums having some space below.

Further inspection reveals that in my case line 156:

Code: Select all

if (i == storage->firstUserCategory)
{
  usercat_pos = root_count;
}

is never true as storage->firstUserCategory equals storage->patch_category.size() (the for loops maximum). As soon as I add a user patch the menu is shown as it probably should be. This also should explain why it didn't work in all my tests but worked on EvilDragon's 2004 machine where Surge is probably regularily used.

One question out of interest: how is VSTGUI integrated in the Visual Studio solution? I haven't found any source files or "MF_MENUBARBREAK" when searching the solution. I got to the win32optionmenu.cpp file by creating a compile error in it using a text editor and opening it from Visual Studio's compile output when surge-headless didn't compile any more. I might have to add that I'm not familiar with CMake and was very pleasently surprised when I got the created project to compile by cloning with recursion and running CMake. This is not a common experience when glancing at bigger open source projects.