KeyboardModifiers...

**graeme** · 10th May 2006, 19:53

I've just noticed an odd behaviour of my program and I'm not certain if it is an issue with my system and so I was wondering if anyone else has experienced it.

I have a widget which traps mouse clicks and looks at the key modifier, doing different actions depending upon the modifier pressed at the time. However if I alt + tab to another application and then go back to my application it believes that the alt key is still pressed. <edit> Pressing and releasing the modifier key will undo this situation<edit>

Further investigation demonstrates the same behaviour for any modifier key that is held down whilst my application is in focus and then switching (say by a mouse click) to another application and then back again. I don't believe it is my system set up since it only happens if my application has focus but I'm not rullign that out. I run Fedora Core 4, KDE and QT 4.1.2.

Essentially has anyone experienced this behaviour before?

**hardgeus** · 10th May 2006, 20:40

What you're describing is a pretty common problem I've run into with a lot of programs, not just QT programs. If a program is keeping track of the state of a keypress, such as whether the TAB key is down, and the tab key is released when another program is active, this can cause the program to eternally think the tab key is down until it is pressed again. This is because they key state is based on events rather than polling, and if the release event occurs in another program, there's no way for your program to know. I have no idea what the solution to this is, but I'm just chiming in to let you know I've run into it many times.

**jpn** · 10th May 2006, 20:50

I can't reproduce this either on WinXP or Kubuntu Breezy (both have Qt 4.1.2 installed).
Did you test this with a minimal compilable example? Just to assure it's not a bug of yours..

**graeme** · 10th May 2006, 21:55

I ran your code and it worked fine on my computer. However, I think that the attached is a minimalist piece of code which does reflect the problem.

To get it I need to use signals and slots. If there is anything wrong with the code (apart from I've not resized anything to fit nicely!) please let me know but it does illustrate the situation on my machine.

**jpn** · 10th May 2006, 22:26

Ahh, it's the QApplication::keyboardModifiers() vs. QInputEvent::modifiers() which makes this notable difference.
I was able to get correct results by catching table widget's mouse press and release events.