I don't have a definite answer to your question, and for sure AWT docs
may be a bit lacking,
but there's also a lot of them so an answer may be buried somewhere.
Not sure if you are saying you are in fact running "arbitrary code" in
removeNotify() but
I don't think that would be a good idea. You can observe in there but
I'm not sure
you should "do" anything. Also per the docs you need to call the
superclass method as the first line.
There's this old bug report https://bugs.openjdk.org/browse/JDK-4074274
which might be useful to read.
-phil.
On 11/6/23 11:53 AM, Alan Snyder wrote:
I have experienced a problem related to Container.remove(index).
As this code has been around for a long time, I’m wondering (1) why it does
what it does and (2) whether
there is some AWT/Swing design rule that I should be following (but I don’t
know of one that would have helped).
The implementation of Container.remove(index) first identifies the component at
the specified index in the component list.
It then calls removeNotify on that component and calls removeLayoutComponent on
its layout manager.
Only then does it remove the component from the component list.
The problem is that is uses the original index to remove the component from the
component list, which
presumes that the previous calls to removeNotify and removeLayoutComponent have
not done anything
to alter the component list.
As both of these methods can run arbitrary client code, the presumption seems
unwarranted.
In my case, removeNotify eventually was called on a focused text field, which
caused the text field
to lose focus, which generated events, and an event handler removed the same
component from the
container.
What am I missing?
