Container.remove issue

[Philip Race]

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?
>