<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello,<br>
Since this fix caused a few regressions I suggest to revert it
back.<br>
<br>
15.10.2012 18:36, Tim English wrote:<br>
</div>
<blockquote cite="mid:SNT117-W15F2ACCB1FB19A62E98FA492710@phx.gbl"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
<div dir="ltr">
Oleg,<br>
<br>
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.<br>
<br>
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. <br>
<br>
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!)<br>
<br>
Cross platform is why I use and love Java. Windows, Mac,
Linux, etc. consistency is the key<br>
<br>
Thanks for the diligence,<br>
Tim<br>
<br>
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.<br>
<br>
<div>
> Date: Mon, 15 Oct 2012 11:09:17 +0400<br>
> From: <a class="moz-txt-link-abbreviated" href="mailto:oleg.pekhovskiy@oracle.com">oleg.pekhovskiy@oracle.com</a><br>
> To: <a class="moz-txt-link-abbreviated" href="mailto:tim_english@hotmail.com">tim_english@hotmail.com</a><br>
> CC: <a class="moz-txt-link-abbreviated" href="mailto:denis.fokin@oracle.com">denis.fokin@oracle.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:artem.ananiev@oracle.com">artem.ananiev@oracle.com</a>;
<a class="moz-txt-link-abbreviated" href="mailto:awt-dev@openjdk.java.net">awt-dev@openjdk.java.net</a><br>
> Subject: Re: [8] Review request for 7171412: awt Choice
doesn't fire ItemStateChange when selecting item after
select() call - approved<br>
> <br>
> Hi Tim,<br>
> <br>
> I'm researching changes made for 6770017 in order to
decide whether we <br>
> could revert them<br>
> or do it another way and return back firing of
ItemStateChange always <br>
> for all platforms.<br>
> <br>
> Thanks,<br>
> Oleg<br>
> <br>
> 10/8/2012 4:39 PM, Tim English wrote:<br>
> > Oleg,<br>
> > I just saw your earlier email as well. I apologize
that I do not have <br>
> > an automated test. I did review the ".2" change and
I am glad that you <br>
> > all went with the better fix by eliminating the
duplicate/triplicate <br>
> > state. Thank you for keeping me in the loop directly
as I have not <br>
> > been keeping up with the digests.<br>
> > All,<br>
> ><br>
> > Thought in hindsight... maybe the original
enhancement request should <br>
> > have just been rejected. If the user keeps picking
the same item from <br>
> > the list, they are probably expecting the software
to do something! It <br>
> > is possible for an event listener to check against
previous state and <br>
> > ignore extra messages(work around possible), it is
NOT possible for an <br>
> > event listener to react to an event that is NEVER
fired (no work <br>
> > around, must redesign UI).<br>
> > > BTW, native Choice controls fire event always
on all platforms.<br>
> > Similar reasoning might lie behind why the native
platforms choose to <br>
> > always fire: more flexibility to the developer.<br>
> > Another possiblity would be to add a new control
state to the Choice <br>
> > control [ set/isFireAlreadySelected() ] and/or the
selection Event [ <br>
> > isAlreadySelected() ]. Default state for
isFireAlreadySelecteded() <br>
> > defaults to true to retain compatibility for older
JVMs. User <br>
> > requesting the original enhacement could set this to
false to silence <br>
> > the repeated selection methods.<br>
> > Note that the original enhancement requester could
have created a <br>
> > Choice subclass to solve the duplicate firing
result. (pseudo code)<br>
> > class SingleFireChoice extends Choice {<br>
> > Listeners singleFirelisteners;<br>
> > addSingleFireListener(Listener
onlyWantsToKnowIfChanged);<br>
> > ... code to filter out duplicate selects<br>
> > }<br>
> ><br>
> > I normally consider that the behavior between radio
groups and choice <br>
> > lists should operate on the same rules. (Just 2
different views of the <br>
> > same information) I wonder if radio groups fire an
extra message if <br>
> > you keep clicking the same radio button over and
over again? It might <br>
> > be an interesting experiment.<br>
> ><br>
> > I just happened to run an old Java utility that I
wrote in 2000. I <br>
> > had not run it since Java7 has been released.<br>
> > It is still using an old 1.4 runtime, and as I was
running it, I <br>
> > realized that it will NOT work with the Java 7 JVM
since it performs <br>
> > an operation when a choice item is selected. The
user might want to <br>
> > perform the same operation repeatedly via the choice
on different inputs.<br>
> ><br>
> > Basic test case that will now fail in the
application is<br>
> > 1. enter some text in TextArea "left"<br>
> > 2. enter some text in TextArea "right"<br>
> > 3. select an operation from the choice (left
difference, right <br>
> > difference, symmetric difference, union,
intersection)<br>
> > 4. review result in TextArea "result"<br>
> > 5. change the text in "left" or "right" or both of
the areas<br>
> > 6. select the SAME operation again from the choice.<br>
> > In J6 and lower, it will perform the operation on
the new inputs.<br>
> > In J7, nothing will happen and there is no way to
know that the <br>
> > user has attempted something.<br>
> ><br>
> > For step 6 to work in Java7 even after the patch for
7171412, I will <br>
> > have to switch to a different item and then switch
back to the desired <br>
> > item.<br>
> > For upgrading the application to work reasonably
with Java7 I will <br>
> > need to add a separate "evaluate" button to "fire"
the choice or else <br>
> > change the choice items into individual buttons.<br>
> ><br>
> > Thanks for looking into this. With all the recent
press on the <br>
> > security items recently, I wasn't sure when someone
would get a chance <br>
> > to look into it. (My Personal Rant about security:
Why do people allow <br>
> > untrusted sites to run active X or applets in the
first place? duh?)<br>
> > I thank you all for your work on this,<br>
> > Tim English<br>
> ><br>
> ><br>
> > > Date: Thu, 4 Oct 2012 13:33:59 +0400<br>
> > > From: <a class="moz-txt-link-abbreviated" href="mailto:oleg.pekhovskiy@oracle.com">oleg.pekhovskiy@oracle.com</a><br>
> > > To: <a class="moz-txt-link-abbreviated" href="mailto:denis.fokin@oracle.com">denis.fokin@oracle.com</a><br>
> > > CC: <a class="moz-txt-link-abbreviated" href="mailto:artem.ananiev@oracle.com">artem.ananiev@oracle.com</a>;
<a class="moz-txt-link-abbreviated" href="mailto:awt-dev@openjdk.java.net">awt-dev@openjdk.java.net</a>; <br>
> > <a class="moz-txt-link-abbreviated" href="mailto:tim_english@hotmail.com">tim_english@hotmail.com</a><br>
> > > Subject: Re: [8] Review request for 7171412:
awt Choice doesn't fire <br>
> > ItemStateChange when selecting item after select()
call - approved<br>
> > ><br>
> > > Hi Denis,<br>
> > ><br>
> > > there are behavior differences for Choice
across the platforms.<br>
> > > on Windows - if we choose the same item twice
ItemStateChange is not<br>
> > > fired twice but for other platform it is so.<br>
> > > There is a separate issue about that 7159935,
so all platform should<br>
> > > behave like Windows does.<br>
> > ><br>
> > > BTW, native Choice controls fire event always
on all platforms.<br>
> > ><br>
> > > Thanks,<br>
> > > Oleg<br>
> > ><br>
> > > 10/3/2012 5:47 PM, Denis S. Fokin wrote:<br>
> > > > Hi Oleg,<br>
> > > ><br>
> > > > the fix looks good. It was interesting to
verify the functionality on<br>
> > > > Linux. On my Ubuntu everything works
properly.<br>
> > > ><br>
> > > > Thank you,<br>
> > > > Denis.<br>
> > > ><br>
> > > > On 10/2/2012 6:48 PM, Artem Ananiev wrote:<br>
> > > >> Hi, Oleg,<br>
> > > >><br>
> > > >> the new version looks fine.<br>
> > > >><br>
> > > >> Thanks,<br>
> > > >><br>
> > > >> Artem<br>
> > > >><br>
> > > >> On 10/2/2012 4:30 PM, Oleg Pekhovskiy
wrote:<br>
> > > >>> Hi Artem,<br>
> > > >>><br>
> > > >>> thank you for the review, I made
changes you proposed there:<br>
> > > >>>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~bagiras/8/7171412.2">http://cr.openjdk.java.net/~bagiras/8/7171412.2</a><br>
> > > >>><br>
> > > >>> Please tell if everything is ok.<br>
> > > >>><br>
> > > >>> Thanks,<br>
> > > >>> Oleg<br>
> > > >>><br>
> > > >>> 10/1/2012 2:23 PM, Artem Ananiev
wrote:<br>
> > > >>>> Hi, Oleg,<br>
> > > >>>><br>
> > > >>>> (adding Tim to copy)<br>
> > > >>>><br>
> > > >>>> the fix looks fine. Could you
please make selectedIndexID just a<br>
> > > >>>> static variable in
awt_Choice.cpp instead of AwtChoice member?<br>
> > > >>>><br>
> > > >>>> Thanks,<br>
> > > >>>><br>
> > > >>>> Artem<br>
> > > >>>><br>
> > > >>>> On 10/1/2012 2:09 PM, Oleg
Pekhovskiy wrote:<br>
> > > >>>>> Hi!<br>
> > > >>>>><br>
> > > >>>>> Please review the fix for
CR:<br>
> > > >>>>>
<a class="moz-txt-link-freetext" href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171412">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171412</a><br>
> > > >>>>><br>
> > > >>>>> Webrev:<br>
> > > >>>>>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~bagiras/8/7171412.1/">http://cr.openjdk.java.net/~bagiras/8/7171412.1/</a><br>
> > > >>>>><br>
> > > >>>>> I left the idea of the fix
CR 6770017 but refused of using <br>
> > doubling<br>
> > > >>>>> native variable for
storing previously selected index<br>
> > > >>>>> (that also caused the
problem described in the current issue).<br>
> > > >>>>><br>
> > > >>>>> Thanks,<br>
> > > >>>>> Oleg<br>
> > > >>><br>
> > > ><br>
> > ><br>
> <br>
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Best regards, Sergey. </pre>
</body>
</html>