richselect/combo & _html field

Discontinued products DHTMLX Touch
#1

It appears that when a richselect/combo component is closed, there can be a

html fragment that is left behind. There appears to be some code designed for IE GC that might be causing the problem. Starting at line 2496:

//temp html element, used by toHTML
if (this._html)
document.body.appendChild(this._html); //need to attach, for IE’s GC

this._html = null;

The append is attaching the

fragment to the DOM. But the next line is removing the pointer without deleting the HTML from the DOM.

One possible solution is to do this:

//temp html element, used by toHTML
if (this._html) {
document.body.appendChild(this._html); //need to attach, for IE’s GC
dhx.html.remove(this._html);
}
this._html = null;

Thanks,
Kris

#2

We will investigate the issue, normally it was expected that destructor will be called mainly before page reloading, so attaching elements to the dom will not cause any harm.

Unfortunately deleting html element is not enough for IE’s garbage collector, table related html tags must be attached to the dom, to correctly collected.

#3

it was expected that destructor will be called mainly before page reloading

Does this mean that windows not longer needed should not be closed?
Windows should be hidden and left in the DOM?

#4

You need not care about memory leaks - all components on page will be destroyed on page unloading.

As for windows - if you plan reuse it, it will be better to hide not close. When window is hidden it is detached from the DOM - so it will not affect performance

If you will not use the same window second time - you can call any of hide or close. From logic point the “close” is more clear way to define that you will not use this window anymore, but from practical side - both commands are good.

#5

all components on page will be destroyed on page unloading.

Sorry but my app does not do any page unload/reload activity.

When window is hidden it is detached from the DOM - so it will not affect performance

Thank you for that piece of information, I didn’t notice that.

Thanks,
Kris

#6

Sorry but my app does not do any page unload/reload activity.
I’m not sure about your app, but I think in most cases app is limited to the fixed set of views ( it is quite rarely, when app need to create new views dynamically ) - in such case you can create all necessary view and just bring them to the screen by showing windows or switching active view in multiview ( in both cases hidden views are detached from the dom and ignore rendering while in invisible state )

We will include fix for destructors anyway, but still in most cases there is no need for direct destructor call .