How to prevent ID collision of objects

[SCAI_Andre]

Hi,

what is the best practice to prevent the following error:

Specified ID:MyObjectID collides with the ID for an existing SmartGWT component or object.

The pseudo code that leads to this situation is as follows:
- Create a HLayout and add it to the screen.
- Create and add several other widget to this HLayout
Manually assign these other widgets (Buttons, dynamicforms, listgrid) own, static IDs like listgrid.setID("myListgrid");
- Let the user interact with the screen
- later on remove the HLayout from the screen by invoking removeMember(myHLayout)
- destroy even the class instance that created these elements to be sure, that are no references any more
- No try to recreate the HLayout and the child widgets with exactly the same IDs as above.

You will get errors in the log like the one on top of this post that complain, that components with these IDs are already there.

Now the question is: What exactly triggers the destruction of objects so that their IDs are free again?

Note that in my example even the class instance that created the widgets is destroyed.

But it still does not work. Do I have some other reference there to the objects which prevent their destruction? How can I check for that?

I need the exact IDs for my selenium test cases where I need exactly the same IDs for each test iteration to allocate the controls in the selectors appropriately.

Thanks in advance,
Andre

[SCAI_Andre]

I'm sorry, forgot to mention that I'm using SmartGwt, not only SmartClient.

Using the developer console I realized that really a lot canvii do net get destroyed as I expected.

While a listgrid vanishes from the object inspector if it is removed from the parent, there are many isc_PickListMenu_XX-objects that remain there, even after the dynamic form containing the respective comboxitem has been removed by "markForDestroy()".

The whole mechanism what, when and how something has to been to be removed cleanly is not transparent to me. I read the API docs but the forementioned best practice is not obvious to me.

TIA

A.

[Isomorphic]

destroy() the top-level UI contain and anything automatically created is cleaned up, or it's reuse is automatically managed. Nothing else is needed - no removeMember() calls, etc. If you're getting collisions, then you're not actually doing this - simplify your code until you see the problem. If you end up with simplified code that still seems to exhibit a problem and you think its a bug, post the code in runnable form and we can look at it.

[SCAI_Andre]

Isomorphic. Thanks for clarifying, that destroy() is the way to go. And it DOES work, except for one thing:
I have main parent HLayout I render to all the time.

To this main parent one additional layout called myAdditionalLayout ist added.

To myAdditionalLayout I add a dynamic form with 5 comboboxitems.

Then I kill myAdditionalLayout by using
myAdditionalLayout.destroy();

Everything is removed now, with the exception that there are several isc_PickListMenu_XX still visible in the Developer Console, exactly 5 pieces.

I then repeat this and end up with 5 more isc_PickListMenu_XX-items in the Developer Console after myAdditionalLayout.destroy();

Why is this? Sorry, no test case, yet, but maybe the reason is obvious without one.

TIA

Andre

[SCAI_Andre]

I see that in the showcase that in the developer console the isc_PickListMenu-items remain there even after the window for the sample "Local and Databound Combox" is closed.

When I reopen it, these items seem to get reused. It looks as if that is not the case in my code.

What prevents reusing these? Why should I want this reusing? The items in the list need to be requeried anyway. I cannot use this kind of caching mechanism if that is the use case for this.

TIA

[Isomorphic]

Picklists are reused when possible, they are pooled and the system makes decisions about when to reuse them. If you've identified a situation where the number of PickLists can grow in an unbounded fashion, let us know and please show a test case that would allow the problem to be reproduced.