Get display object by .id?

Solar2D General Questions/Discussion
#1

You can get it by key, as per https://forums.coronalabs.com/topic/42759-how-do-you-access-display-objects-in-a-display-group-using-the-display-objects-variable-name/

But is there also a way to get it by ID from the parent or ultimate parent (e.g. self.view)? You’d optimally want to set and get using a string or number property (as long as it doesn’t turn into an iteration behind the scenes…) Something like myView viewWithTag:myTag] in Objective-C.

That is, by reference (not having to loop through all display objects on the screen…)

Display objects are key-value tables, so you could add any custom key as property. But this won’t help since you would have to iterate and match on the property value.

The normal solution is to keep track of them in an external table. Even going by reference here will ultimately end up in some sort of iteration, but hopefully a low-level one that is efficient(?)

So I guess what I’m looking for the same table used by display.* for garbage collection or similar? As long as it will let me set the key for the display object in that table, and not just get it. Or one like it, introduced in Corona.

#2

Accessing objects in a display group works exactly the same way as accessing them in a table by integer index, because they are the same.

If you want to access them by name you would have to assign a name by either the dot syntax

myDispGroup.myDispObj

Or by named index

myDispGroup[myDispObj]

This is also the same as named table indexing.

If you want to avoid iterating on a display group to find a display object, just add a named reference to it when you add it to the group. The side-effect here is that, unlike with tables, the object will be found in the group by both name and integer index, but that is not really an inconvenience.

If a display group is disposed of, any of it’s referenced objects will be garbage collected at the same time, unless they are reference by something else in memory.

#3

If the code
self.view[“myGeneratedIDString”]=display.newRect(0,0,100,100)

is valid, then getting and setting by direct reference is solved. Is it?

This will still not quite be the same as a viewWithTag correspondence, because normally you will want various parent groups and objects parenting the object that you have the ID of, for completely other reasons than direct indexing.

Ideally, you’d want the .id as a reference from the ultimate parent for this task. In essence, the same-old external flat table, but one kept by Corona as it keeps the pointers for GC (although that is very likely not flat).

#4

Accessing objects in a display group works exactly the same way as accessing them in a table by integer index, because they are the same.

If you want to access them by name you would have to assign a name by either the dot syntax

myDispGroup.myDispObj

Or by named index

myDispGroup[myDispObj]

This is also the same as named table indexing.

If you want to avoid iterating on a display group to find a display object, just add a named reference to it when you add it to the group. The side-effect here is that, unlike with tables, the object will be found in the group by both name and integer index, but that is not really an inconvenience.

If a display group is disposed of, any of it’s referenced objects will be garbage collected at the same time, unless they are reference by something else in memory.

#5

If the code
self.view[“myGeneratedIDString”]=display.newRect(0,0,100,100)

is valid, then getting and setting by direct reference is solved. Is it?

This will still not quite be the same as a viewWithTag correspondence, because normally you will want various parent groups and objects parenting the object that you have the ID of, for completely other reasons than direct indexing.

Ideally, you’d want the .id as a reference from the ultimate parent for this task. In essence, the same-old external flat table, but one kept by Corona as it keeps the pointers for GC (although that is very likely not flat).