Mouse cursor disappears when renaming a modulation source to a same-length or longer name

[Marat-Tanalin]

When entering a new name (before even saving the new name with the Enter key) during renaming a custom modulation source (one from the right four columns), mouse cursor gets invisible above any DAW window, including the one with Surge itself.

When running in bridged mode (as a separate or dedicated process), as expected, just the plugin area gets cursorless while other DAW windows are unaffected.

Interestingly, when the name is changed to a shorter one (e.g. from test to tes) during renaming, cursor does not disappear.

If to move mouse before saving the new name, the cursor gets visible again.

Mouse cursor returns to a visible state once the Win key is pressed or a left/right click is made.

The issue does not depend on zoom chosen in Surge settings.

Desktop:

• OS: Windows 10 Pro (1809 build 17763.437).
• Reaper 5.974 (64 bit).
• Surge 1.6.0-beta-8 (64 bit).
• 4K monitor at 200% OS-level zoom.

[baconpaul]

This windows code is basically unchanged since inception; I looked and it doesn’t inherit the cursor hiding behavior of sliders (which was my guess) but is rather a complete native CDialogImpl<> thingy in src/common/gui/PopupDialogEditor - look for the spawn_miniedit

the mac implementation is totally different and the linux one doesn’t exist (there’s an issue for that) so debugging this is for someone who knows how windows dialogs (as opposed to vstgui drawing) works.

I am not such a person! But I looked in the code and didn’t see anything obvious like “window.hideCursor()” so this one requires some real debugging.

[baconpaul]

Oh and the dialog definition is in src/common/windows/surge.rc; it is the first dialog which is used here. The second one (the old save dialog before Claes ported it to vstgui) is unused.

I am assuming one of the options somewhere in the dialog definition or setup is suppressing the mouse. don’t know which one. Any help from windows dialog folks appreciated...

[mortfell]

I was just about to report this also. Unfortunately I also have no ideas about what might be causing this.

[baconpaul]

So I have to do some windows debugging before we ship 162. Let me tag this for that release and I will at least try. Not sure I can fix it but can’t hurt to look once more

[mortfell]

Sure, I'll let you know if I notice anything interesting related to this

[baconpaul]

Ugh - this is just a mess of ancient windows code I don't understand. Most of which is pulled in just for this one tiny dialog.

I'm going to bounce this to 1.6.3. And in 1.6.3 I may just re-implement this dialog to be cross platform anyway.

[mkruselj]

I'm going to bounce this to 1.6.3. And in 1.6.3 I may just re-implement this dialog to be cross platform anyway.

Really sounds like the most sane thing to do!

[baconpaul]

I'm gonna consolidate this into #1465