I stand corrected. It is Component.removeNotify (called on a text field that is the focus owner) that clears the global focus owner, triggering a focus changed event.
My point is that my application code is not violating the advice about removeNotify, but the problem still occurs because my focus event listener is “doing something”. Hence my question, is there (or should there be) advice about event listeners not “doing something”? I still see no reason for Container.remove not to employ defensive programming. Maybe 20 years ago the performance cost of an extra array reference was considered a problem, but I can’t see it being a problem today. Alan > On Nov 8, 2023, at 10:49 AM, Philip Race <[email protected]> wrote: > > The AppContext.remove() call just removes an entry from a map and doesn't > affect the UI. > And anyway the caution is about application code doing something. > > -phil. > > On 11/7/23 3:31 PM, Alan Snyder wrote: >>> On Nov 7, 2023, at 2:57 PM, Philip Race <[email protected]> wrote: >>> >>> 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. >>> >> >> Interesting, but In this case, it is JTextComponent that is “doing >> something”. >> >> public void removeNotify() { >> super.removeNotify(); >> if (getFocusedComponent() == this) { >> AppContext.getAppContext().remove(FOCUSED_COMPONENT); >> } >> } >> >> Is there similar advice not to “do something” in a focus event listener? >> >> I’m not seeing an argument against using some “defensive programming” in >> Container.remove. >> >> It would be odd if some application depended upon removing a different >> component. >> >> Alan >> >
