On 03/05/2014 05:39 PM, Anthony Petrov wrote:
On 3/5/2014 4:47 PM, Yuri Nesterenko wrote:
On 03/05/2014 04:17 PM, Anthony Petrov wrote:
we do not know the location of the TrayIcon on the screen.
Oh yes, we do! We could use the Robot to capture a screen image and then
locate our icon in that image (provided we use a unique-enough icon).
Well, I'm not suggesting you to implement this now. :)
Just a side note: in some of our tests we use reflection to call methods
of a peer for that. It does even work! You cannot be sure it will
always work but then again, what does?
Note that this verifies a part of the code only, because you bypass the
native code (and the operating system code) with such a test.
Nope: we find that location and then click there by the robot.
It's just a hint. Unfortunately, from time to time we have false
positives. For instance, on Solaris 10 x64 a private
method getLocationOnScreen of XTrayIconPeer returns
zero x coordinate, and the test fails -- but icon is in a correct place.
As it is a deep and private method, I even cannot complain, I'm afraid.
-yan
--
best regards,
Anthony
-yan
The fix looks good to me.
--
best regards,
Anthony
On 3/5/2014 1:13 PM, Petr Pchelko wrote:
Hello, AWT team.
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-7158615
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/7158615/webrev/
I'm open sourcing these tests, the difference is that on Mac the
TrayIcon action event is triggered by the right mouse button, not left.
The tests could not be converted to automatic as we do not know the
location of the TrayIcon on the screen.
With best regards. Petr.
