Oddity and bug with polled input and Notify()

BlitzMax Forums/BlitzMax Programming/Oddity and bug with polled input and Notify()

TomToad(Posted 2010) [#1]
I thought I'd share a problem I found and the solution I came up with. Here is a sample program

When you press Q, the happy count goes up and when you press Shift-Q, the happy count goes down. If you try to remove happiness when it is already 0, a notify box pops up
Now is when things get strange. After clicking OK on the notify box, you press Q once and nothing happens. When you press it a second time, it tries to remove the happy even though Shift is no longer pressed.
After thinking about it for a while, I figured out the problem. Seems the Notify() window takes focus away from the BMax window and it no longer receives Key events. So when you take your hands off the keyboard to click on OK, BMax doesn't detect it and thinks the keys are still pressed.
When you press Q the first time, nothing happens because BMax thinks the key is already pressed, but when you release it, BMax then recieves the EVENT_KEYUP event and so it will work the second time. Not really since now BMax still thinks the Shift key is down. The only way to get the keys working properly again is to press and release shift once, then press Q twice.

The only fix I've been able to find is to put a FlushKeys() after the Notify(). But this isn't ideal because if the user needs to keep the Shift key down for some reason, then BMax will think the key is no longer pressed.

Anybody think of any better solution?


Jesse(Posted 2010) [#2]
BlitzMax does not have a way to test if a key is continually down which fails in something like your code. I suggest you look for an alternative such as using your own built gui to report the happy/sad state.


Czar Flavius(Posted 2010) [#3]
I stopped using Notify as well as Confirm in my program for this reason and also the reason they do not always display correctly when in full-screen - which is no good for a game.