bug(windows): scroll lock appears to reset context in compliant and non-compliant apps

[mcdurdin]

Use contextreset.zip from #11172. We tested ^Scroll Locke, and expected ê but got e. If we did the same thing but with Num Lock, we got ê as we expected. This was true for both compliant and non-compliant apps (because ^ was generating a marker (dk), and context resets in compliant apps drop markers).

The relevant table in Keyman Core shows:

keyman/core/src/vkey_to_contextreset.cpp

Lines 154 to 155 in ba8dcad

	false, //L"K_NUMLOCK", // &H90
	false, //L"K_SCROLL", // &H91

which suggests that Scroll Lock and Num Lock should have the same behaviour.

18.0.202-beta or thereabouts.

[mcdurdin]

@rc-swag and @ermshiperete fyi

[mcdurdin]

I consider this low priority to fix but high priority to investigate in case there is a more significant issue going on behind the scenes.

[rc-swag]

I have done some testing with the test host. The vkey value is 3 when a scroll lock is pressed on a lenvo keyboard. This means from the look up table to determine a contest reset returns true.
NumLock actually doesn't even reach core processing at all. I think this maybe to do with preserved key functionality.

[mcdurdin]

The vkey value is 3 when a scroll lock is pressed on a lenvo keyboard.

Weird. Here's what I get (Microsoft keyboard, Keyman Developer key identifier):

What do you get in Keyman Developer?

[rc-swag]

What do you get in Keyman Developer?

With the Virtual Key I identifier, I get the same as the screenshot attached above, scan code 46. If I debug a keyboard and press scrolllock the debugger displays ?Ctrl+Break and doesn't add anything to the context.
I also tested test host with the microsoft OSK and the vkey value was again 3

[mcdurdin]

OK, 3 is VK_Break which is also on the Scroll Lock key. We may have some confusion somewhere there but for now I don't think we need to take this further. The impact is minimal (loss of context) on a key which doesn't even exist on many hardware keyboards! Let's push this out to a low-priority further investigation sometime in the 19.0 cycle.

[rc-swag]

see also #13179