Oh, I'm really sorry about that ! I removed the comment, a new webrev is at : http://cr.openjdk.java.net/~zhouyx/7155298/webrev.03/
Please take a look again. Thanks ! On Sat, Mar 24, 2012 at 1:50 AM, Anton V. Tarasov <anton.tara...@oracle.com>wrote: > ** > Hi Sean, > > XTextAreaPeer.java: > > + // visible caret has a timer thread which must be stopped+// > jtext.getCaret().setVisible(false); > ^^^ > > Seems that you forgot the comments in the webrev. > > The new test looks fine to me. > > Thanks, > Anton. > > > On 23.03.2012 10:49, Sean Chou wrote: > > > I modified the testcase according to Anthony Petrov's suggestion( > http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002389.html) . > The new webrev: http://cr.openjdk.java.net/~zhouyx/7155298/webrev.02/ > > However, the timeout action in jtreg only checks the main method, but > the timeout is caused by timer thread . > So, I started an other process to run the testcase and the main testcase > waitFor that process to stop. In order to kill the process started by the > testcase, I added a ShutdownHook to the runtime of main testcase. And added > /othervm action to testcase . > > It seems the testcase is a little over complex, is there any other > method to make the testcase simpler ? > > On Fri, Mar 23, 2012 at 2:04 AM, Oleg Sukhodolsky <son....@gmail.com>wrote: > >> On Thu, Mar 22, 2012 at 10:50 PM, Anton V. Tarasov >> <anton.tara...@oracle.com> wrote: >> > On 3/22/12 6:15 PM, Oleg Sukhodolsky wrote: >> >> >> >> On Thu, Mar 22, 2012 at 5:55 PM, Anton V. Tarasov >> >> <anton.tara...@oracle.com> wrote: >> >>> >> >>> On 22.03.2012 14:37, Oleg Sukhodolsky wrote: >> >>>> >> >>>> On Thu, Mar 22, 2012 at 2:19 PM, Anton V. Tarasov >> >>>> <anton.tara...@oracle.com> wrote: >> >>>>> >> >>>>> On 22.03.2012 12:47, Oleg Sukhodolsky wrote: >> >>>>>> >> >>>>>> On Thu, Mar 22, 2012 at 12:01 PM, Sean Chou< >> zho...@linux.vnet.ibm.com> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> Hi Oleg, >> >>>>>>> >> >>>>>>> Seem there are misunderstanding . >> >>>>>>> DefaultCaret can receive FocusLostEvent when another control >> get >> >>>>>>> focused. But it >> >>>>>>> doesn't receive FocusLostEvent when disposing. >> >>>>>>> >> >>>>>>> The reason is XTextAreaPeer doesn't receive FocusLostEvent >> when >> >>>>>>> disposing. But >> >>>>>>> I don't know if it is a rule that a FocusLostEvent must be sent to >> >>>>>>> the >> >>>>>>> focused>>> component when the top-level window is disposed ? >> >>>>>> >> >>>>>> Well, for regular AWT component it is expected. And I'd expect >> that >> >>>>>> this should also be true for peer. >> >>>>> >> >>>>> >> >>>>> That's right, focus_lost should be dispatched to a disposed focus >> >>>>> owner. >> >>>> >> >>>> So, now we need to figure out why the caret doesn't get the event. >> >>>> >> >>>> Oleg. >> >>> >> >>> >> >>> I ran the testcase provided in the webrev and debugged a little. >> >>> FOCUS_LOST >> >>> does come to the textarea on its disposal, though when the focus >> event is >> >>> being dispatched I see the peer is null. >> >>> This is quite expected actually. When Component.removeNotify() is >> called >> >>> on >> >>> EDT, it transfers focus further (appropriate focus events get queued) >> and >> >>> then nullifies the peer. The events come later. >> >>> Hope this helps. >> >> >> >> Thank you (I do not have Linux, so I can not debug this). >> >> So, now we know that the cause of the problem is that our internal >> >> AWTText(Field|Area) may be disposed while they think >> >> that they are focused, and, at the same time, we can not propogate >> >> real focus lost to them since peer is desposed >> >> before we receive the event. >> >> So, the suggested fix works fine for one particular problem (unstopped >> >> timer), but we may get some other >> >> problems due to the cause. >> >> For me it looks like better fix would be to pass synthetic focus lost >> >> when we dispose text peer, this way we guarantee >> >> that life-circle of our synthetic components will be similar to real >> >> ones and we will meet Swing's expectations. >> >> >> >> Does this sounds reasonable? >> >> >> >> Regards, Oleg. >> > >> > >> > This sounds reasonable, though I personally don't like the idea of yet >> > another synthetic focus event... >> >> well, (synthetic) focus events are your area of expertise ;) >> >> > I actually like the fix Sean suggested (after we see the whole picture). >> > Otherwise, we may follow your suggestion >> > to create AWTTextArea.removeNotify(). And even simpler, why not to put >> > getCaret().setVisible(false) right into JTextComponent.removeNotify()? >> >> well, the later is a question for Swing team. >> The former is reasonable fix (not the best one, but good enough). >> So, if everyone agree with this approach then I'm fine (hope this is >> the only problem we >> will have with invisible focused JTextXXX) >> >> Oleg. >> >> > >> > Either of these looks fine to me. >> > >> > Thanks, >> > Anton. >> > >> > >> > > > > -- > Best Regards, > Sean Chou > > > -- Best Regards, Sean Chou
