<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
Mon Mar 14 14:26:11 UTC 2016


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/20160314/832838a4/attachment-0001.html>


More information about the awt-dev mailing list