PolledInput flushes keys/mousebutton on suspend/resume

[GWRon]

Create a simple graphical window.

SuperStrict
'Framework Brl.Retro
Import Brl.Graphics
Import Brl.GLMax2D
Import Pub.Win32



SetGraphicsDriver GLMax2DDriver()
Graphics 800,600


Function MyHook:Object( id:Int,data:Object,context:Object )
	Local ev:TEvent=TEvent(data)
	If Not ev Return data

	Print "event: "+ev.id +"  data="+ev.data	
End Function
AddHook EmitEventHook,MyHook,Null,0

While Not (KeyHit(KEY_ESCAPE) Or AppTerminate())
 	DrawText "A = "+KeyDown(KEY_A), 0, 200

	Flip
	Cls
Wend

Hold "A" and Alt-Tab (needed, as clicking "somewhere into another window" does not emit suspend-events).
Keep holding "A" and Alt-Tab back into your window.

For BlitzMax "A" is no longer "down/hold" - as it flushes keys / mouse buttons.

Ok. If you now removed the flushkeys/flushmouse commands when suspending/resuming your app, you could release "A" while suspended but for blitzmax it is "down/hold" when alt-tabbing in again - and it keeps "hold" until you tap "A" again.

[GWRon]

One potential solution is to create some backup-arrays for the key and mouse states/hit-count.

When now suspending the app we iterate over all key/mouse states/hit-counts and backup them right before flushkey and flushmouse are called.

When now resuming the app, we iterate over all keys and mouse buttons (+ mouse location[2] as this is scroll wheel). During this iteration we need to refresh the current state of the key/button.

There are some possibilities:
it differs:
In that case we have to emit an event (as if it was coming from the OS) that a button/key is now down/up
hit-count needs to be kept reset as done by flushkeys and flushmouse.

it's the same:
Restore backup'd hit-count for the key/button (so "keyrepeat" and the likes work correct)

Problem I cannot solve for now: we need ways to check current key/button states of the OS.
For Windows we have GetKeyState:Short(key:int) we could use.
For Linux we could use https://tronche.com/gui/x/xlib/input/XQueryKeymap.html
or maybe we use something in the likes as:
https://www.unknowncheats.me/forum/c-and-c-/183880-linux-detecting-key-held-simulating-getasynckeystate.html

But for Mac I have no clue what would fit.

[woollybah]

It also needs to be done in a backend-agnostic way, so that when SDL implement it, I can just update state from their list. I imagine events are the easiest thing to implement - and they’d be generated from systemdefault.

…

On 13 Feb 2018, at 13:37, Ronny Otto ***@***.***> wrote: One potential solution is to create some backup-arrays for the key and mouse states/hit-count. When now suspending the app we iterate over all key/mouse states/hit-counts and backup them right before flushkey and flushmouse are called. When now resuming the app, we iterate over all keys and mouse buttons (+ mouse location[2] as this is scroll wheel). During this iteration we need to refresh the current state of the key/button. There are some possibilities: it differs: In that case we have to emit an event (as if it was coming from the OS) that a button/key is now down/up hit-count needs to be kept reset as done by flushkeys and flushmouse. it's the same: Restore backup'd hit-count for the key/button (so "keyrepeat" and the likes work correct) Problem I cannot solve for now: we need ways to check current key/button states of the OS. For Windows we have GetKeyState:Short(key:int) we could use. For Linux we could use https://tronche.com/gui/x/xlib/input/XQueryKeymap.html or maybe we use something in the likes as: https://www.unknowncheats.me/forum/c-and-c-/183880-linux-detecting-key-held-simulating-getasynckeystate.html But for Mac I have no clue what would fit. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[GWRon]

Yes, the basic idea should be to "emulate" the missed information-events - at least if they are of "interest": means:

• keys/buttons down in all cases
• keys/buttons up on resume if down on suspend

In that case the events should get emitted so the default BlitzMax-implementation (SDL or "vanilla implementation") receives them as if the OS emitted key/button changes in a normal running/focused application.

"hitcount" is used somewhere, so the count should be restored - or the reset avoided. If the reset is avoided it must made sure to reset properly on a real "key up".