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 ?
On Thu, Mar 22, 2012 at 2:42 PM, Oleg Sukhodolsky <son....@gmail.com> wrote:
> Hi Sean,
>
> comments inlined.
>
> On Thu, Mar 22, 2012 at 10:15 AM, Sean Chou <zho...@linux.vnet.ibm.com>
> wrote:
> > Hi Oleg,
> >
> > I replaced the TextArea with JTextArea in the test and the
> application
> > exits.
> > With some code added to DefaultCaret.java after invocation to
> flasher.stop ,
> > I got
> > a stack trace as follow, which is not seen in test with TextArea.
> >
> > java.lang.RuntimeException: my exception 2
> > at javax.swing.text.DefaultCaret.setVisible(DefaultCaret.java:985)
> > at javax.swing.text.DefaultCaret.focusLost(DefaultCaret.java:364)
> > at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:230)
> > at java.awt.Component.processFocusEvent(Component.java:6396)
> > at java.awt.Component.processEvent(Component.java:6260)
> > at java.awt.Container.processEvent(Container.java:2229)
> > at java.awt.Component.dispatchEventImpl(Component.java:4860)
> > at java.awt.Container.dispatchEventImpl(Container.java:2287)
> > at java.awt.Component.dispatchEvent(Component.java:4686)
> > at
> >
> java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1908)
> > at
> >
> java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:937)
> > at
> >
> java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:611)
> > at java.awt.Component.dispatchEventImpl(Component.java:4730)
> > at java.awt.Container.dispatchEventImpl(Container.java:2287)
> > at java.awt.Component.dispatchEvent(Component.java:4686)
> > at sun.awt.SunToolkit$4.run(SunToolkit.java:588)
> > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
> > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705)
> > at java.awt.EventQueue.access$000(EventQueue.java:101)
> > at java.awt.EventQueue$3.run(EventQueue.java:666)
> > at java.awt.EventQueue$3.run(EventQueue.java:664)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at
> >
> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
> > at java.awt.EventQueue.dispatchEvent(EventQueue.java:675)
> > at
> >
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211)
> > at
> >
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
> > at
> >
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
> > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
> > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
> > at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
> >
> >
> > So, the difference is when disposing, if JTextArea is used, DefaultCaret
> > receives a focusLost event;
> > if TextArea is used, DefaultCaret does not receive that event.
>
> Does DefaultCaret receives focusGained for TextArea?
> If yes, perhaps we should investigate why it doesn't receive focusLost
> and fix this (who knows what other
> problems could be introduced by invisible focused JTextArea)
>
> > I also instrumented forwardFocusLost and found it is not invoked when
> > disposing (this can be
> > seen from the above stack trace as well) .
> >
> > But I can't answer the question whether
> > AWTTextArea/AWTTextField.removeNotify()
> > should stop the timer. Swing-dev is added to cc list.
>
> AWTTextArea/AWTTextField are our own classes, so it is we who
> responsible to decide
> whether added some calls to thier methods or not.
>
>
> Regards, Oleg.
>
> >
> > On Wed, Mar 21, 2012 at 9:14 PM, Oleg Sukhodolsky <son....@gmail.com>
> wrote:
> >>
> >> Hi Sean,
> >>
> >> as far as I understand the caret and the timer both come from Swing,
> >> thus I wonder why
> >> calling removeNotify() on JPasswotrdField/JTextArea doesn't stop the
> >> timer? What does Swing expect?
> >> It might be some bug in Swing (I hope it is not, but it is better to
> >> verify ;)
> >>
> >> As for changes I'd suggest to move this additional call (if we decide
> >> that this is the right way to fix the problem) into
> >> AWTTextArea/AWTTextField.removeNotify() this will help in case we
> >> decide to call it in some other place.
> >>
> >> Regards, Oleg.
> >>
> >> On Wed, Mar 21, 2012 at 11:55 AM, Sean Chou <zho...@linux.vnet.ibm.com>
> >> wrote:
> >> > Hi all,
> >> >
> >> > It is found that when TextArea or TextField is setEditable(true),
> >> > the
> >> > application will not exit after the application frame disposes.
> >> > The reason is the visible caret contains a timer which controls its
> >> > flashing
> >> > . This timer must be stopped when disposing.
> >> >
> >> > Link to webrev: http://cr.openjdk.java.net/~zhouyx/7155298/webrev.00/
> >> > Link to bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155298
> >> >
> >> > --
> >> > Best Regards,
> >> > Sean Chou
> >> >
> >
> >
> >
> >
> > --
> > Best Regards,
> > Sean Chou
> >
>
--
Best Regards,
Sean Chou
