WinGUI: getch() doesn't return on shift+keypad

[HunterZ]

Using MSYS2 provided mingw64/mingw-w64-x86_64-pdcurses 4.3.1-1 package on Windows 11.

I've got my program building, linking, and running, but I noticed an odd problem: getch() simply stays blocked if I hold down shift while typing any of keypad 0-9 or keypad ., as if I hadn't pressed a key at all. Other keypad keys ('/' '*' '-' '+' and enter) work fine. Shift + regular cursor keys works fine as well.

Shift+keypad also works fine with wincon (which was much harder to get working), so it seems to be a WinGUI specific issue?

[Bill-Gray]

Got the same problem here when running the "input test" section of testcurs.exe on Wine. Haven't puzzled it out yet. Will investigate tomorrow (need sleep now.)

When you say it was hard to get WinCon working : it shouldn't be any more difficult than WinGUI. Perhaps an issue for that as well? Generally speaking, I'd suggest WinGUI over WinCon; the latter is quite limited in comparison. But for one reason or another, a lot of people still seem to like WinCon, and we do try to keep it working.

[HunterZ]

Opened a separate issue for WinCon as suggested.

While we're on the subject of keypad quirks: I haven't tried your fork's SDL2 flavor yet (because MSYS2 doesn't include it in their package manager), but vanilla PDCurses' SDL2 support also has its own odd shift+keypad behavior: It acts like you typed a number instead of a keypad key! Fortunately I am able to deduce that it's a keypad key by way of the shift modifier being present.

[Bill-Gray]

Quick/dirty fix to Shift-Numpad issues on WinGUI requires adding these lines :

--- a/wingui/pdcscrn.c
+++ b/wingui/pdcscrn.c
@@ -1413,6 +1413,11 @@ static void HandleSyskeyDown( const WPARAM wParam, const LPARAM lParam,
 
     if( key > ' ' && key < KEY_MIN && ctrl_pressed && !alt_pressed)
        add_key_to_queue( key);
+    else if( shift_pressed)
+    {
+       if( (key >= '0' && key <= '9') || key == '.')
+          add_key_to_queue( key);      /* Shift-numpad cases */
+    }

This is sufficiently narrowly aimed that I have confidence it works, but I may look for other cases before committing code.

The bit where SDL2 responds to Shift-Numpad with a digit and a Shift modifier is the way it's supposed to work. ncurses does the same, minus the modifier. However, at least on my machine, SDL2 gives two number-plus-Shift modifiers each time. (Also happens in plain PDCurses, which is unsurprising; SDLn support in PDCursesMod is basically a copy of PDCurses with a few bits modified.) You didn't mention it, so maybe it's a Linux thing.

[HunterZ]

Interesting that digit+modifier is the intended behavior, as that's clearly not what happens with WinCon (which worked without my digit+modifier logic).

I did not notice any double register issues with plain PDCurses SDL2 on Windows 11. I suppose it could be specific to Linux (as you said), or even the particular version of SDL used.

[Bill-Gray]

Commit eacd04d1aa460a1912c22300670ee51a3 should fix this. We do still have the inconsistencies between platforms as to what you get with Shift-numpad key hits.

Just fired up the Win10 box and I also don't see double-hits on Windows 10 with SDL2; the only place it happens is SDL2 on Linux. I'll give it another look; if I can't figure it out (entirely possible), I'll see if I can tempt William into looking at it (but I'd rather be able to say "here's the problem and the fix for it" instead of "here's the problem which I've no idea how to fix").

[Bill-Gray]

Finally figured out why we get duplicate Shift-Numpad hits on SDL2 and fixed it (commit 9b86c29aa1f86fe486a6119f9). @wmcbrine, this may be of interest to you, as the problem and its fix applies to PDCurses as well.

[GitMensch]

Sounds like this is solved, no?

[Bill-Gray]

(Pause to investigate and scratch head) Yes, this is done and can/should be closed.