Qt5 native messages not propogated?

[ComServant]

I'm not suggesting Qt intentionally interacts with third party APIs. All I'm saying is that Win32 messages that previously reached a third party library in Qt 4.8 (and in Qt 4.7, and I think 4.6 also), now are not reaching it in Qt 5, even though it's still reaching the QWidget. I'm not asking for Qt to forward anything. I'm asking why it's blocking what it previously wasn't.

I don't understand how the QWidgets are implemented in Win32, but I'm wondering if a perhaps in the promotion of QWidgets to their own module, as well as any possible QPA code changes, Qt 5 might be accidentally blocking certain Win32 messages. Again, not knowing how it works under the hood, I wonder if perhaps it's failing to call DefWndProc() on a few messages that used to call it on. If so, why the change? If the change is accidental, what other side-effects might this cause in compatibility?

Why does it forward some Win32 messages but not others? Why not forward them all? Why not block them all? A change was made that affects the Win32 events that reach the window. The question is, why? What purpose does it serve, and was it accidental?

[wysota]

I'm not suggesting Qt intentionally interacts with third party APIs. All I'm saying is that Win32 messages that previously reached a third party library in Qt 4.8 (and in Qt 4.7, and I think 4.6 also), now are not reaching it in Qt 5, even though it's still reaching the QWidget. I'm not asking for Qt to forward anything. I'm asking why it's blocking what it previously wasn't.

How were they "reaching" the library?

Why does it forward some Win32 messages but not others? Why not forward them all? Why not block them all? A change was made that affects the Win32 events that reach the window. The question is, why? What purpose does it serve, and was it accidental?

If you want to handle windows events then install a native event filter on the application object.

[ComServant]

I'm not sure. I'll just looked at the source of SFML, and this is what it looks like:

1. Qt creates the window
2. Qt gives me the HWND
3. I give SFML the HWND
4. SFML attaches it's own WndProc callback function to it, but saves the previous (Qt's) WndProc.
5. SFML receives the messages, processes them, then forwards them to the previous (Qt's) WndProc.

So it looks like SFML gets to process the Win32 events before Qt. I don't know why SFML is not processing the key presses (but is receiving mouse messages) then, but why it was previously with Qt 4.8.

It looks like I was investigating the wrong API - thanks for the help.

[neosettler]

Greetings,

I've been on this case for awhile now and I still couldn't figure why SFML does not process mouse wheel and keyboard inputs anymore.

Could you tell us how you fixed it?

Note: It is clearly a QT modification from 4.8 to 5.x that brought this issue.

Thank you!

[ComServant]

It's definitely a Qt issue, and I haven't gotten it working. I'm using Qt 5.0.1 - maybe someone has fixed it in a more recent update, but I can't check anytime soon.

I receive events for: Mouse movement and mouse button presses (include the middle button, which is the scroll wheel), but I don't receive events for mouse wheel movement or keypresses, even though the QWidget is clearly getting them.

I wonder if Qt treats mouse wheel in the same way as keypresses, and whether it is failing to call the Win32 DefWindowProc on them, or something.

[wysota]

Please provide a minimal compilable example demonstrating the problem.