<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 21 09:51:10 UTC 2016


Thanks!

On 3/18/2016 8:46 PM, Semyon Sadetsky wrote:
> Looks good.
>
> --Semyon
>
> On 3/17/2016 10:15 AM, 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

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


More information about the awt-dev mailing list