In your example the gtk sends the message to Form1 and TWinControl.IsControlMouseMsg sends it further to TPaintBox.Where does the win32 interface send the wheel messages to?
Ok, after this discussion i think i figured out whats wrong: Win32 does indeed send the message to TForm (much like GTK does, as you say) *but* the coordinates are in screen space, not client space (which explains the incorrect translation i mentioned in my original post), so the IsControlMouseMsg thinks that the message is for TForm instead of TPaintBox because it gets incorrect coordinates (the rest of LCL seems to think that wheel messages are always in client space). Bringing them in client space when the WM_MOUSEWHEEL event decides that this is a message for us (at the end of the message handling in 'case') produces the correct behaviour for the test program (and my 3D app) under Windows. Also the received coordinates are in the same space with the rest of the mouse events.
I attached a patch against revision 15355 that does exactly that. This patch is in the Windows callback function, so the problem is probably now fixed where it began from.
Kostas
win32-mousewheel-event-coords-fix.patch
Description: Binary data
_______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
