The fix looks good to me.
Thanks,
Alexandr.
On 17/03/16 11:15, Alexander Stepanov wrote:
Hello Alexandr,
> it should be created and used on EDT
the following methods affecting UI are run on EDT: UI(),
showDialogOrFrame() and dispose() operations in doTest (the final
'dispose' is indeed should be run on EDT as well). The robot
operations/checks are executed on main thread using volatile/final
references to get the coordinates.
But if this is still not safe enough, then this 'extends JFrame' could
be easily removed as it doesn't make any special sense.
Please see the updated fix:
http://cr.openjdk.java.net/~avstepan/8151714/webrev.02/
(the transform-based scale check was also removed as it seems that the
fix for JDK-8150844 is near to be pushed).
Thanks,
Alexander
On 3/16/2016 8:55 PM, Alexander Scherbatiy wrote:
The MultiResolutionJOptionPaneIconTest extends JFrame so it shoud be
created and used on EDT as others Swing components.
Thanks,
Alexndr.
On 14/03/16 18:26, Alexander Stepanov wrote:
Hello Semyon,
> JOptionPane.showInternalInputDialog() is an utility method
Yes, the initial intention was to check the icons for all the
dialogs created by means of these utilities. But in principle these
options could be skipped, and the test could be limited by checking
the icons for JOptionPane's createDialog() and createInternalFrame()
methods.
In such a case the test indeed may be easily converted to the
automated one.
> What doesn't work exactly, the dispose() call?
Please disregard. Simply shouldn't create and dispose the dialog at
the same EDT.
So please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8151714/webrev.01/
Thanks,
Alexander
On 3/11/2016 8:38 PM, Semyon Sadetsky wrote:
On 3/11/2016 7:38 PM, Alexander Stepanov wrote:
> just call dispose().
1.
SwingUtilities.invokeAndWait(() -> {
JOptionPane.showInternalInputDialog(...); });
r.waitForIdle();
dispose what? no reference to the dialog shown. or do you mean
again use of component tree?
JOptionPane.showInternalInputDialog() is an utility method.
2.
this trivial way:
JOptionPane op = new JOptionPane(msg, info, opt, icon);
JDialog dlg = op.createDialog(parentPane, "test");
SwingUtilities.invokeAndWait(() -> { dlg.setVisible(true); });
r.waitForIdle(2000);
dlg.dispose();
- doesn't work as well until "ok" button isn't pressed by the user
(and it differs from the initial test variety). not sure if it
could be fixed by some thread tricks.
What doesn't work exactly, the dispose() call?
--Semyon
Thanks,
Alexander
On 3/11/2016 7:17 PM, Semyon Sadetsky wrote:
On 3/11/2016 6:33 PM, Alexander Stepanov wrote:
> traverse the component tree
Hm, interesting. But I'm not sure if everything is smoothly as,
e.g., it is also required to close the dialogs one-by-one (for
now the user does that), and I'm not sure if it is easy to
implement.
Seriously? It is damn easy: just call dispose().
On 3/11/2016 5:55 PM, Semyon Sadetsky wrote:
On 3/11/2016 5:45 PM, Alexander Stepanov wrote:
*inside of the internal pane
parent pane
On 3/11/2016 5:42 PM, Alexander Stepanov wrote:
Hello Semyon,
I'm not sure if we can control the location of the dialogs
shown (and of course we don't know the location of the icons
on them), can we?
Yes, we can: Component# getLocationOnScreen() and traverse the
component tree to find the Label component with the icon.
--Semyon
It is clear that the internal dialogs are located somewhere
inside of the internal pane, but this is not true for the
others.
So (probably I'm wrong) there is seemingly no an elegant way
to predict the location of the icons, and simple iteration
over the screen coordinates (checking for the pixel color)
looks not very reliable.
Thanks,
Alexander
On 3/11/2016 5:24 PM, Semyon Sadetsky wrote:
Hi Alexandr,
Can the test be automated? It is possible to read color from
the screen with AWT Robot.
--Semyon
On 3/11/2016 4:53 PM, Alexander Stepanov wrote:
Hello,
Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8151714/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8151714
- just a single test added.
Thanks,
Alexander
