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.
Thanks,
Anton.
Anyone from AWT team,
what is the current policy for forwarding focus events to peers?
Focus events are forwarded to peers. Look at the very end of
Component.dispatchEventImpl(AWTEvent).
Thanks,
Anton.
Reagds, Oleg.
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
