Custom window header controls not cleaned up

[stonebranch2]

Hello Isomorphic,

We have a window class that sets custom header controls, like follows.

refreshHeaderCtrl = new HeaderControl(HeaderControl.REFRESH, new ClickHandler() {

    @Override
    public void onClick(ClickEvent event) {
        onRefreshClicked();
    }
});
closeHeaderCtrl = new HeaderControl(HeaderControl.CLOSE, new ClickHandler() {

    @Override
    public void onClick(ClickEvent event) {
        onCloseClicked();
    }
});
headerSpacer = new LayoutSpacer();
headerSpacer.setWidth(15);
setHeaderControls(headerSpacer, HeaderControls.HEADER_LABEL, refreshHeaderCtrl, closeHeaderCtrl);

The controls may or may not remain hidden until the window is destroyed.

I noticed in the Watch tab that after closing the window, those custom header controls appear parentless, undrawn, and do not seem to be destroyed.

I assumed the window would destroy them, however, I also tried adding the following, which no luck.

Thanks

@Override
public void destroy() {
    super.destroy();
    if (refreshHeaderCtrl != null) {
        refreshHeaderCtrl.destroy();
        refreshHeaderCtrl = null;
    }
    if (closeHeaderCtrl != null) {
        closeHeaderCtrl.destroy();
        closeHeaderCtrl = null;
    }
    if (headerSpacer != null) {
        headerSpacer.destroy();
        headerSpacer = null;
    }
}

Is there something I am missing that I should be doing to clear these header controls up?

SmartClient Version: v9.1p_2014-08-31/Pro Deployment (built 2014-08-31)
FF 24.8.0

[Isomorphic]

Can you clarify what you mean when you say the header controls may remain hidden until the window is destroyed?

Standard SmartGWT behavior should cause parents to recursively destroy their children, so it is likely that if the controls are visible they will be destroyed along with the window, but if they haven't been added as children, this wouldn't happen.
There may be a something we can address in the framework to improve the behavior but without a clearer picture of your use case it's hard for us to proceed.

Perhaps the best thing to do would be to expand your code snippet a little to show us enough that we can actually run your code (so create a header control, create a window, apply it, using whatever logic you're currently using to ensure it doesn't show up, then destroy the window).

Thanks
Isomorphic Software

[stonebranch2]

I picked up SmartClient Version: v9.1p_2014-09-17/Pro Deployment (built 2014-09-17) and I am no longer experiencing the issue.

As for your question "Can you clarify what you mean when you say the header controls may remain hidden until the window is destroyed?", I should have included an additional line in the example code provided earlier.

refreshHeaderCtrl = new HeaderControl(HeaderControl.REFRESH, new ClickHandler() {

    @Override
    public void onClick(ClickEvent event) {
        onRefreshClicked();
    }
});
closeHeaderCtrl = new HeaderControl(HeaderControl.CLOSE, new ClickHandler() {

    @Override
    public void onClick(ClickEvent event) {
        onCloseClicked();
    }
});
headerSpacer = new LayoutSpacer();
headerSpacer.setWidth(15);
setHeaderControls(headerSpacer, HeaderControls.HEADER_LABEL, refreshHeaderCtrl, closeHeaderCtrl);
[B]
// By default, only refresh button visible. This "close" header control could possibly remain hidden until the window is destroyed.
closeHeaderCtrl.setVisible(Boolean.FALSE);
[/B]

[Isomorphic]

Ok. Thanks for following up. Good to know this isn't being an issue for you anymore. If it does resurface, please let us know and we'll take a look. It might be helpful if this does occur for you to assemble your code snippet into an actual EntryPoint class we can actually run -- this will ensure we're really able to see exactly what you're experiencing.

Regards
Isomorphic Software