Topics

dispose on JComponents

Svata Dedic
 

Hi,

a newbie question: where exactly dispose() is supposed to be called ?
I understand that dispose() was meant to do a cleanup, and understand the function in a top-down hierarchies.

But JComponent has its removeNotify() called when it gets off the parent; so is there are a part of JComponent lifecycle, when the component was *already* removed, but can be activated again ?

Asking because the cascading of dispose() in DecoderPro duplicates the same cascade of removeNotify() and it be unnecessary to track 'components to dispose' if the same is already tracked by the component hierarchy itself.

Thanks,
-Svata

Randall Wood <rhwood@...>
 

In an AWT GUI, dispose is called when native resources are no longer needed. https://docs.oracle.com/javase/8/docs/api/java/awt/Window.html#dispose-- so this method is available to AWT Frames, Dialogs, Windows, and their Swing equivalents.

Within JMRI, that idiom is also used for tearing down complex structures (so in some contexts dispose() on a subclass of JComponent is called by something else for some other reason).

It is entirely possible that we may have implemented dispose on JComponents when we should have implemented removeNotify() instead.

Randall

On Oct 6, 2019, at 07:07, Svata Dedic <svatopluk.dedic@...> wrote:

Hi,

a newbie question: where exactly dispose() is supposed to be called ?
I understand that dispose() was meant to do a cleanup, and understand the function in a top-down hierarchies.

But JComponent has its removeNotify() called when it gets off the parent; so is there are a part of JComponent lifecycle, when the component was *already* removed, but can be activated again ?

Asking because the cascading of dispose() in DecoderPro duplicates the same cascade of removeNotify() and it be unnecessary to track 'components to dispose' if the same is already tracked by the component hierarchy itself.

Thanks,
-Svata



Svata Dedic
 

Dne 06. 10. 19 v 13:29 Randall Wood via Groups.Io napsal(a):
Within JMRI, that idiom is also used for tearing down complex structures (so in some contexts dispose() on a subclass of JComponent is called by something else for some other reason).
OK. Asking bcs. JMRI JComponents that I saw typically connect themselves to collaborators in constructors, so they're not much usable after dispose().

So the remaining case is that even though the component is removed, should _still_ be fully functional (i.e. to be re-added, whatever) - then dispose() is needed to release linkek stuff on time. Is there such a pattern to be aware of ?

-Svata

Randall Wood <rhwood@...>
 

I think we don’t want to be reusing components between Windows. Do look at JmriJFrame however, it does allow a window to be rendered non-displayable, manipulated, and then redisplayed (to allow some Jython manipulation of a window). I don’t know how that feature interacts with add/removeNotify.

Randall

On Oct 6, 2019, at 09:19, Svata Dedic <svatopluk.dedic@...> wrote:

Dne 06. 10. 19 v 13:29 Randall Wood via Groups.Io napsal(a):
Within JMRI, that idiom is also used for tearing down complex structures (so in some contexts dispose() on a subclass of JComponent is called by something else for some other reason).
OK. Asking bcs. JMRI JComponents that I saw typically connect themselves to collaborators in constructors, so they're not much usable after dispose().

So the remaining case is that even though the component is removed, should _still_ be fully functional (i.e. to be re-added, whatever) - then dispose() is needed to release linkek stuff on time. Is there such a pattern to be aware of ?

-Svata




Bob Jacobsen
 

JMRI’s use of overridden versions of java.awt.Window#dispose() [1] dates back to the earliest versions that used Java 1.1.8. That’s somewhat separate from JComponent#removeNotify(), which I don’t think we use very much. A lot of that early code built functionality right into JFrame classes, without any real idea of life cycle, MVC separation or anything else[2].

It might be very useful to clarify how JMRI code should use dispose(), removeNotify, and perhaps other “conventional clean up” methods.

There was (briefly) an effort to clean up frame and component use via a defined initialization sequence in JmriJFrame et al, see https://www.jmri.org/help/en/html/doc/Technical/Swing.shtml But that never got a lot of traction…

Bob


[1] and hence javax.swing.JFrame#dispose(); I don’t think that javax.swing.JComponent doesn’t have a dispose() method, and a JFrame isn’t a JComponent.

[2] The code that became JMRI was using Swing before it was even called Swing, with some of the JFC-using[3] code dating back as least as far as Fall 1997. Lots of things were different then.

[3] Swing evolved from the Java Foundation Class (JFC) effort, at least in part.

On Oct 6, 2019, at 4:07 AM, Svata Dedic <svatopluk.dedic@...> wrote:

Hi

a newbie question: where exactly dispose() is supposed to be called ?
I understand that dispose() was meant to do a cleanup, and understand the function in a top-down hierarchies.

But JComponent has its removeNotify() called when it gets off the parent; so is there are a part of JComponent lifecycle, when the component was *already* removed, but can be activated again ?

Asking because the cascading of dispose() in DecoderPro duplicates the same cascade of removeNotify() and it be unnecessary to track 'components to dispose' if the same is already tracked by the component hierarchy itself.
--
Bob Jacobsen
@BobJacobsen

Svata Dedic
 

Dne 06. 10. 19 v 17:59 Bob Jacobsen napsal(a):
There was (briefly) an effort to clean up frame and component use via a defined initialization sequence in JmriJFrame et al, see https://www.jmri.org/help/en/html/doc/Technical/Swing.shtml But that never got a lot of traction…
Thanks for the info.
[2] The code that became JMRI was using Swing before it was even called Swing, with some of the JFC-using[3] code dating back as least as far as Fall 1997. Lots of things were different then.
:) I missed those heroic times. I joined Swing / NetBeans development only during Java 1.2.x.

-Svata