Hi Sergey, I have not been able to find any example of different behaviour between index based and object based logic, so I have made the changes on Mac as you suggested. Also, on Linux, I found that the Choice.java class holds a selectedIndex already, so I removed it in XChoicePeer.java, and tested it. Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8014503/webrev03/ <http://cr.openjdk.java.net/~kaddepalli/8014503/webrev03/>
Thanks, Krishna > On 23-Aug-2018, at 4:34 PM, Sergey Bylokhov <sergey.bylok...@oracle.com> > wrote: > > Hi, Krishna. > On 20/08/2018 04:30, Krishna Addepalli wrote: >> Yes, the behavior is not because of the fix I made. I was trying to >> understand the implications of the index based selection approach, and now >> it looks to be consistent on all the platforms. >> On Mac, as per your suggestion, we can get the same behavior by removing the >> "setSelectedItem", but my question is, should I make this change or keep the >> index based change, since that would keep the implementation also consistent >> across platforms. > > Can you please provide an example which will show the difference between > these two solutions. > > btw initially the code in setSelectedItem(..) was added to fix the opposite > bug. And current fix will skips some events which are generated to fix the > opposite bug, it looks strange. > >> Thanks, >> Krishna >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Tuesday, August 14, 2018 7:52 AM >> To: Krishna Addepalli <krishna.addepa...@oracle.com>; Ajit Ghaisas >> <ajit.ghai...@oracle.com>; Shashidhara Veerabhadraiah >> <shashidhara.veerabhadra...@oracle.com>; awt-dev@openjdk.java.net >> Subject: Re: <AWT Dev> [12]RFR : JDK-8014503: AWT Choice implementation >> should be made consistent across platforms. >> On 13/08/2018 11:06, Krishna Addepalli wrote: >>> The fix I propose is modeled after the code in Windows, which tracks items >>> by their selected index. The code in Mac is storing currently selected >>> object, which could raise the question about which object to select next, >>> when the selected object is removed/changed. >>> With index based approach, I see that, the index remains unchanged, even if >>> the object at that location is removed/changed, unless it causes the index >>> to be out of bounds. >>> This behavior is the same across Windows, Linux and Mac. >> I guess behavior is the same, because of the shared code in >> Choice->remove->removeNoInvalidate >> which selects the new element if the old selected element was removed. >> And it is not affected by the code changed in the fix. > > > -- > Best regards, Sergey.
