<AWT Dev> [8] Review request for 7171412: awt Choice doesn't fire ItemStateChange when selecting item after select() call - approved

Oleg Pekhovskiy oleg.pekhovskiy at oracle.com
Mon Dec 10 04:18:50 PST 2012 

Hi Sergey,

I absolutely agree with you, the only thing is that when we revert the 
fix, on Windows platform it will behave differently in comparison with 
other platforms.
The best solution would be to make Window's combo box fire event each 
time the user chooses an item in the drop-down list even if he selects 
the same item once again.
This is how Choice behaves on other platforms. But such behavior was 
changed in 6770017 to eliminate incorrect functionality described in the 
bug.

Thanks,
Oleg

12/10/2012 3:46 PM, Sergey Bylokhov wrote:
> Hello,
> Since this fix caused a few regressions I suggest to revert it back.
>
> 15.10.2012 18:36, Tim English wrote:
>> Oleg,
>>
>> The inability to use a Choice as an "action" driver could be a huge 
>> change for some applications as they upgrade to 7.0 and definitely 
>> warrants re-consideration.
>>
>> It seemed like a reasonable enhancement request, and as developers we 
>> just LOVE creating new stuff and fixing stuff that is not working.  I 
>> fell into the same trap... find the fix for the current problem.
>>
>> I am thinking of various action, validation or navigation 
>> strategies based on Choices that are affected.  e.g. Choice selection 
>> opens certain detail dialog. User closes dialog, adjusts values on 
>> main form,  and wants to view the same detail dialog again. (No event 
>> fired!)
>>
>> Cross platform is why I use and love Java. Windows, Mac, Linux, etc.  
>> consistency is the key
>>
>> Thanks for the diligence,
>> Tim
>>
>> P.S. The QA person who made the regression entry about failing a test 
>> is probably thinking "No one ever listens to QA."  :-) Maybe they can 
>> update comments or documentation around the original QA test 
>> case that failed that captures the "action driver" aspect of why this 
>> should not fail.
>>
>> > Date: Mon, 15 Oct 2012 11:09:17 +0400
>> > From: oleg.pekhovskiy at oracle.com
>> > To: tim_english at hotmail.com
>> > CC: denis.fokin at oracle.com; artem.ananiev at oracle.com; 
>> awt-dev at openjdk.java.net
>> > Subject: Re: [8] Review request for 7171412: awt Choice doesn't 
>> fire ItemStateChange when selecting item after select() call - approved
>> >
>> > Hi Tim,
>> >
>> > I'm researching changes made for 6770017 in order to decide whether we
>> > could revert them
>> > or do it another way and return back firing of ItemStateChange always
>> > for all platforms.
>> >
>> > Thanks,
>> > Oleg
>> >
>> > 10/8/2012 4:39 PM, Tim English wrote:
>> > > Oleg,
>> > > I just saw your earlier email as well. I apologize that I do not 
>> have
>> > > an automated test. I did review the ".2" change and I am glad 
>> that you
>> > > all went with the better fix by eliminating the duplicate/triplicate
>> > > state. Thank you for keeping me in the loop directly as I have not
>> > > been keeping up with the digests.
>> > > All,
>> > >
>> > > Thought in hindsight... maybe the original enhancement request 
>> should
>> > > have just been rejected. If the user keeps picking the same item 
>> from
>> > > the list, they are probably expecting the software to do 
>> something! It
>> > > is possible for an event listener to check against previous state 
>> and
>> > > ignore extra messages(work around possible), it is NOT possible 
>> for an
>> > > event listener to react to an event that is NEVER fired (no work
>> > > around, must redesign UI).
>> > > > BTW, native Choice controls fire event always on all platforms.
>> > > Similar reasoning might lie behind why the native platforms 
>> choose to
>> > > always fire: more flexibility to the developer.
>> > > Another possiblity would be to add a new control state to the Choice
>> > > control [ set/isFireAlreadySelected() ] and/or the selection Event [
>> > > isAlreadySelected() ]. Default state for isFireAlreadySelecteded()
>> > > defaults to true to retain compatibility for older JVMs. User
>> > > requesting the original enhacement could set this to false to 
>> silence
>> > > the repeated selection methods.
>> > > Note that the original enhancement requester could have created a
>> > > Choice subclass to solve the duplicate firing result. (pseudo code)
>> > > class SingleFireChoice extends Choice {
>> > > Listeners singleFirelisteners;
>> > > addSingleFireListener(Listener onlyWantsToKnowIfChanged);
>> > > ... code to filter out duplicate selects
>> > > }
>> > >
>> > > I normally consider that the behavior between radio groups and 
>> choice
>> > > lists should operate on the same rules. (Just 2 different views 
>> of the
>> > > same information) I wonder if radio groups fire an extra message if
>> > > you keep clicking the same radio button over and over again? It 
>> might
>> > > be an interesting experiment.
>> > >
>> > > I just happened to run an old Java utility that I wrote in 2000. I
>> > > had not run it since Java7 has been released.
>> > > It is still using an old 1.4 runtime, and as I was running it, I
>> > > realized that it will NOT work with the Java 7 JVM since it performs
>> > > an operation when a choice item is selected. The user might want to
>> > > perform the same operation repeatedly via the choice on different 
>> inputs.
>> > >
>> > > Basic test case that will now fail in the application is
>> > > 1. enter some text in TextArea "left"
>> > > 2. enter some text in TextArea "right"
>> > > 3. select an operation from the choice (left difference, right
>> > > difference, symmetric difference, union, intersection)
>> > > 4. review result in TextArea "result"
>> > > 5. change the text in "left" or "right" or both of the areas
>> > > 6. select the SAME operation again from the choice.
>> > > In J6 and lower, it will perform the operation on the new inputs.
>> > > In J7, nothing will happen and there is no way to know that the
>> > > user has attempted something.
>> > >
>> > > For step 6 to work in Java7 even after the patch for 7171412, I will
>> > > have to switch to a different item and then switch back to the 
>> desired
>> > > item.
>> > > For upgrading the application to work reasonably with Java7 I will
>> > > need to add a separate "evaluate" button to "fire" the choice or 
>> else
>> > > change the choice items into individual buttons.
>> > >
>> > > Thanks for looking into this. With all the recent press on the
>> > > security items recently, I wasn't sure when someone would get a 
>> chance
>> > > to look into it. (My Personal Rant about security: Why do people 
>> allow
>> > > untrusted sites to run active X or applets in the first place? duh?)
>> > > I thank you all for your work on this,
>> > > Tim English
>> > >
>> > >
>> > > > Date: Thu, 4 Oct 2012 13:33:59 +0400
>> > > > From: oleg.pekhovskiy at oracle.com
>> > > > To: denis.fokin at oracle.com
>> > > > CC: artem.ananiev at oracle.com; awt-dev at openjdk.java.net;
>> > > tim_english at hotmail.com
>> > > > Subject: Re: [8] Review request for 7171412: awt Choice doesn't 
>> fire
>> > > ItemStateChange when selecting item after select() call - approved
>> > > >
>> > > > Hi Denis,
>> > > >
>> > > > there are behavior differences for Choice across the platforms.
>> > > > on Windows - if we choose the same item twice ItemStateChange 
>> is not
>> > > > fired twice but for other platform it is so.
>> > > > There is a separate issue about that 7159935, so all platform 
>> should
>> > > > behave like Windows does.
>> > > >
>> > > > BTW, native Choice controls fire event always on all platforms.
>> > > >
>> > > > Thanks,
>> > > > Oleg
>> > > >
>> > > > 10/3/2012 5:47 PM, Denis S. Fokin wrote:
>> > > > > Hi Oleg,
>> > > > >
>> > > > > the fix looks good. It was interesting to verify the 
>> functionality on
>> > > > > Linux. On my Ubuntu everything works properly.
>> > > > >
>> > > > > Thank you,
>> > > > > Denis.
>> > > > >
>> > > > > On 10/2/2012 6:48 PM, Artem Ananiev wrote:
>> > > > >> Hi, Oleg,
>> > > > >>
>> > > > >> the new version looks fine.
>> > > > >>
>> > > > >> Thanks,
>> > > > >>
>> > > > >> Artem
>> > > > >>
>> > > > >> On 10/2/2012 4:30 PM, Oleg Pekhovskiy wrote:
>> > > > >>> Hi Artem,
>> > > > >>>
>> > > > >>> thank you for the review, I made changes you proposed there:
>> > > > >>> http://cr.openjdk.java.net/~bagiras/8/7171412.2
>> > > > >>>
>> > > > >>> Please tell if everything is ok.
>> > > > >>>
>> > > > >>> Thanks,
>> > > > >>> Oleg
>> > > > >>>
>> > > > >>> 10/1/2012 2:23 PM, Artem Ananiev wrote:
>> > > > >>>> Hi, Oleg,
>> > > > >>>>
>> > > > >>>> (adding Tim to copy)
>> > > > >>>>
>> > > > >>>> the fix looks fine. Could you please make selectedIndexID 
>> just a
>> > > > >>>> static variable in awt_Choice.cpp instead of AwtChoice member?
>> > > > >>>>
>> > > > >>>> Thanks,
>> > > > >>>>
>> > > > >>>> Artem
>> > > > >>>>
>> > > > >>>> On 10/1/2012 2:09 PM, Oleg Pekhovskiy wrote:
>> > > > >>>>> Hi!
>> > > > >>>>>
>> > > > >>>>> Please review the fix for CR:
>> > > > >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171412
>> > > > >>>>>
>> > > > >>>>> Webrev:
>> > > > >>>>> http://cr.openjdk.java.net/~bagiras/8/7171412.1/
>> > > > >>>>>
>> > > > >>>>> I left the idea of the fix CR 6770017 but refused of using
>> > > doubling
>> > > > >>>>> native variable for storing previously selected index
>> > > > >>>>> (that also caused the problem described in the current 
>> issue).
>> > > > >>>>>
>> > > > >>>>> Thanks,
>> > > > >>>>> Oleg
>> > > > >>>
>> > > > >
>> > > >
>> >
>
>
> -- 
> Best regards, Sergey.

More information about the awt-dev mailing list