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

Mon Oct 15 07:36:36 PDT 2012

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20121015/1bbbcf1d/attachment.html 