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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Mon Dec 10 03:46:59 PST 2012 

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.

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

More information about the awt-dev mailing list