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...
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()?
Either of these looks fine to me.
Thanks,
Anton.
