Solved QFrame steals focus (activateWindow) from another QFrame when activated by Touch
-
Hi,
First off, I'm new here so if I missed some info/guidelines, I'll gladly rectify this post.I'm working on a desktop app that has a QFrame with buttons in it (the buttons are not Qt).
When clicking on one of the buttons, it sends a message to another QFrame (floating QDialog) to activate, get focus and raise.
On a touch screen, when touching the same button, it does the same as clicking but then the focus (activation and raise) goes back to the first QFrame (the one with the buttons).
Since the buttons are not Qt (personnal API), the touch events are handled by Windows and said personal API but researching that direction was inconclusive.
I also reimplemented QFrame::event() to try and see what's going on and all I can see are a bunch of activations and deactivations between the 2 QFrames (Paint events are filtered out):On click (valid scenario):
FloatingQFrame::event: ZOrderChange (126)
QFrameWithButtons::event: InputMethodQuery (207)
FloatingQFrame::event: WindowActivate (24)
FloatingQFrame::event: ActivationChange (99)
QFrameWithButtons::event: WindowDeactivate (25)
FloatingQFrame::event: UpdateRequest (77)On touch (invalid scenario):
FloatingQFrame::event: ZOrderChange (126)
FloatingQFrame::event: WindowActivate (24)
FloatingQFrame::event: ActivationChange (99)
QFrameWithButtons::event: WindowDeactivate (25)
FloatingQFrame::event: UpdateRequest (77)
QFrameWithButtons::event: WindowActivate (24)
FloatingQFrame::event: WindowDeactivate (25)
FloatingQFrame::event: ActivationChange (99)
QFrameWithButtons::event: InputMethodQuery (207)
FloatingQFrame::event: UpdateRequest (77)As you can see, the invalid scenario is pretty much the same as the valid one except for the 2nd half that reactivates the QFrameWithButtons.
It seems to happen when my finger leaves the screen (Touch Up) but those 2 elements don't even register to Qt::WA_AcceptTouchEvents (that's also why there's no TouchEvents in the above prints).
Also tried the WinAPI ::SetFocus direction but also inconclusive (focus would change without a call to the WinUser API).Any idea? Known bug?
Thanks ! -
Hi and welcome to devnet,
No answer yet but some things are missing:
- What Qt version are you using ?
- What version of Windows are you using ?
- What are your custom buttons ?
-
- Qt version is 5.6.0;
- Windows version is 8.1 (though it is reproduce on Windows 10 too);
- Regarding the custom buttons, those are just OpenGL frames that listen to system events (like clicks and stuff). The events they listen to, their graphic behaviors and their logic behavior are defined in a custom-made XML.
It's important to add that I deeply debugged the buttons' behavior in the bug I defined and that direction came inconclusive.
Thanks !
-
Can you check with a more recent version of Qt ? The current LTS is 5.12.3 and Qt 5.13 is around the corner.
-
@SGaist
Unfortunately I can't, it's a very big system and updating the Qt version would be too time-consuming and risky. -
I didn't meant to replace the current running version, just build your application with a more recent version of Qt to test it on your development environment.
-
@SGaist
Hi,
The solution I found for this didn't involve Qt :)
I used the custom buttons API I mentioned earlier and registered its actions on TouchUp instead of TouchDown.
Works like a charm !Thanks !