Correct - automation IDs are maintained in a central map. You'll need to remove the entries yourself if you are no longer using them.
I would strongly recommend the other approach I suggested. It's not difficult and is less fragile. On Jun 6, 2010, at 2:43 PM, aappddeevv wrote: > I’ll check out the automation ID. How does that get set? It kind of looks > like it is just using a giant centralized hash map. My only concern is that > its centralized with strong references which prohibits some gc versus a > component property “name.” > > Perhaps this is the case for attributes (as in an attached property) although > it would be nice if this property were more formalized into an instance > setter/getter. > > > > > From: Greg Brown [mailto:[email protected]] > Sent: Sunday, June 06, 2010 1:36 PM > To: [email protected] > Subject: Re: Component names inside the containers > > One option would be to use the "automationID" property of Component. However, > I think a better approach would be to define a custom subclass of whatever > container type you are using, make it Bindable, and add getters (but not > setters) for each of the components you retrieve from the WTKX file. That > way, you get type safety and you don't need to maintain two different > identifiers for your components. > > On Jun 6, 2010, at 11:09 AM, aappddeevv wrote: > > > I was looking to pass in a container to a method and then pull a few > components out by name (the container has a complex view and the components I > want to access by name are labels, a few labels out of many labels) to do > some processing on. This way I don’t have to add property setters and getters > in my container subclass. In my method, I don’t have access to the serializer > to obtain the components by id. > > However, a component name (an optional) property would do the trick. Is there > a way to assign a string “name” to a component in WTKX and access it later? > In this context, a wtkx:id acts much like a name but as near as I can tell > the wtkx:id is only relevant as a named component in the serializer versus a > property of the component itself. >
