<AWT Dev> [9] RFR for 8151714: [TEST] add a manual test test for JOptionPane dialog multires. icons

Alexander Stepanov alexander.v.stepanov at oracle.com
Thu Mar 17 07:15:22 UTC 2016


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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160317/e4bf6b1f/attachment.html>


More information about the awt-dev mailing list