Old Artifacts Coming Back

[richip]

SmartGWT 2.4

We create several SmartClient GUI objects programmatically and are finding that the second (or succeeding) time around creating the object, we're finding the first one is the one actually being added to its container. Would anyone know or care to guess what would be causing this?

My guess is that HTML elements are being created with the same ID and the previous one isn't being removed from the DOM. Do we have to explicitly destroy or dereference unused SmartGWT elements? (I remember that GWT handlers need to be dereferenced explicityl.) If so, could somebody point me to documentation on the recommended approach to doing this?

Of course, if I'm barking up the wrong tree, I'd love to hear your input.

[Isomorphic]

That's barking up the wrong tree, it's almost certainly a logic bug in your code.

See also the FAQ about mixing GWT and SmartGWT components, if you're doing that, there's an outside chance you could get some kind of effect like this.

[richip]

That's barking up the wrong tree, it's almost certainly a logic bug in your code.

*sigh* Thanks. It was. Because of your statement, I went over the code again and saw the one line that was returning a cached singleton object.

Now that we're properly creating a new instance, however, we're coming up with the following error:

Error :Cannot change configuration property 'ID' to V_100_ENA_SED_rapin_CO_namefor after the component has been created

I'm guessing that creating, destroying and recreating HTML widgets is common enough that there's a recommended method for this. Thoughts?

[Isomorphic]

If you're trying to change the ID after the component has been drawn, that's too late, set it right after creation (right after new SomeWidget()).

We don't know of a valid reason to change ID dynamically.

[richip]

What I'm doing is still a continuation of what I was talking about earlier. Essentially, this is the process that I follow:

1. Create SmartGWT widget hierarchy using new <<SmartGWTWidget>>(). In certain cases (such as for TreeGrids and SectionStacks), I call setID after the constructor
2. Add the returned composite widget into a container in my document (Canvas.addChild())
3. Upon canceling the app, the view is removed from the container (Canvas.removeChild()) and all references to the view are reset
4. On recreation of the task, go to Step 1.

It's on the second execution of Step 1 that I'm getting the error message above about calling setID(). From my logs, I'm seeing that the specific widget that I'm calling setID on are two different objects. Any ideas why it would behave differently in the second instance?

[Isomorphic]

Before you can use the same ID again, you need to destroy() the old widget. See the docs for this method, you probably need just a single call, to the widget at the top of the hierarchy to be destroyed.

[richip]

Before you can use the same ID again, you need to destroy() the old widget. See the docs for this method, you probably need just a single call, to the widget at the top of the hierarchy to be destroyed.

Thanks, that did it.

Interestingly, I wasn't far off with my first conjecture ... except I hadn't created the problem then. I'm assuming Dialogs need to be destroyed as well when done.

[Isomorphic]

Ones you directly create, but not ones created indirectly (SC.say(), the Highlight Editor dialog, etc).