On 10/8/2013 2:01 PM, Petr Pchelko wrote:
Hello, Anthony.
Sorry for the delay, I've got distracted by other fixes. Here's an updated
version of the fix:
http://cr.openjdk.java.net/~pchelko/8025585/webrev.01/
Looks fine.
Thanks,
Artem
So I think we should ignore the SendMessage's return value and always return
TRUE here because the message has already been processed by the target toolkit.
What do you think?
Indeed in case an other toolkit would return false here we would get quite
inconsistent behaviour. So I've updated the fix to always return TRUE.
With best regards, Petr.
On 02.10.2013, at 20:41, Anthony Petrov <anthony.pet...@oracle.com> wrote:
Hi Petr,
The new version looks better. However, there's still one minor issue:
1528 return ::SendMessage(hWndForWheel, msg.message,
mouseWParam, mouseLParam);
The PreProcessMouseMsg() function to which this line belongs should return a
boolean value indicating whether the event must be processed (FALSE) or
silently consumed (TRUE). The ::SendMessage() returns the result of calling a
WndProc() for the target window when it processes the message, which we really
don't care about here. And regardless of the result, I don't think that AWT
should process the message any further after it's been redirected to the target
toolkit.
So I think we should ignore the SendMessage's return value and always return
TRUE here because the message has already been processed by the target toolkit.
What do you think?
--
best regards,
Anthony
On 10/02/2013 05:33 PM, Petr Pchelko wrote:
Hello, Thank you for the review.
It really seems to be an issue. We need another check that hWndForWheel belongs
to the current process, and doesn't sent the event to this window, if it
doesn't.
That was indeed an issue. I've got used to Mac behaviour and did not notice the
problem.
The new version of the fix is available here:
http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/
Now we redispatch the wheel event only if the window is in the same process.
With best regards. Petr.
On Oct 1, 2013, at 9:54 PM, Artem Ananiev <artem.anan...@oracle.com> wrote:
On 10/1/2013 9:17 PM, Anthony Petrov wrote:
Hi Petr,
MS Windows always sends WHEEL events to the focused window. And my
testing shows that when you scroll the wheel outside of an AWT window,
the scroll events are consumed (by AWT, supposedly).
With your fix you seem to always redirect the events to the window under
the mouse. Now suppose you have a 3rd-party window with a scroll bar in
background (e.g. Windows Explorer). If an AWT window is currently
focused, but you move the mouse pointer outside of it and above the
Explorer window, and start scrolling, will the Explorer window scroll
its contents? Currently it doesn't. What about if we apply your fix?
It really seems to be an issue. We need another check that hWndForWheel belongs
to the current process, and doesn't sent the event to this window, if it
doesn't.
Thanks,
Artem
--
best regards,
Anthony
On 09/27/2013 07:24 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8025585
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8025585/webrev.00/
The fix is needed for JFXPanel support. We need to redispatch
MOUSEWHEEL messages to the window under mouse. In case of Popups in a
JFXPanel the HWND belongs to a different tollkit, so we need to use
::SendMessage to redispatch the message.
With best regards. Petr.
