Hi everyone,
I have a question about the display.newGroup().
I insert some graph into one display.newGroup(), like some line, and circle.
Now the problem is I want to change the line’s width which I have already insert into the object. How can I do this? And how can I enum every object I inserted into that display.newGroup().
Thank you very much.
Hello @zy021511,
Generally speaking, if you have objects within a display group that you need to change/edit/remove specifically, you should create a local way to access them… either a local variable, a reference within a table, etc. Although you could technically access the item by its “index” within the display group, it could easily get shifted around if you put other items in the group and move their z-index order around. Thus, to be safe, you should create a dedicated reference to the object and always use that to effect changes on it.
Regards,
Brent
Curious to hear Brents take on this technique…
Hey zy, one thing you can do to keep “handy” access to objects in a group you want to modify later is to include a pointer to them inside the group where they exist.
So to modify an object inside a group later, you could store a pointer to it inside the group where it was inserted, as so
[lua]
local g = display.newGroup()
local myRect = display.newRect(0,0,100,100)
g:insert(myRect)
g.myRect = myRect – Save a pointer to it the code can access later
–
– Later, code anywhere in your app can access the object via
–
g.myRect:toFront()
g.myRect.alpha = 0.5
[/lua]
Sure, that should be fine. The caution is that by placing a reference there, it needs to be removed along with the object. But, I guess that’s really not any different than removing an external reference to the object… just a different pointer to it.
The other caution would be if an object moved groups, suddenly the previous group would have a reference to an object that is no longer inside it.
Personally, I prefer just keeping references external. Easier to track IMHO. 
Brent
Thank you guys, I fix the problem.
I add point to the display group.
Thank you guys very much.
OK, sounds good - wanted to make sure there wasn’t any conflict with how the sdk processes groups if we stored our own pointers / data in there.
Also, I think the memory management takes care of itself this way… As long as you *don’t* store a pointer to your object somehwere else (ie; it’s original pointer created as a local as above, so the reference disappears at end of scope) then the pointer in the group is considered unused once (pointers to) the group it exists in is unused / removed / nil’ed.
At least that’s how it seems to work from here.
@mpappas, you’re correct… and just to clarify (as you probably already know), there are some restrictions on display groups, meaning, they are tables, but their children can’t always be accessed in the same ways as you might access children of normal tables… no ipairs() and no table.insert() into display groups.
Otherwise, you can attach properties/references to groups like normal.
Beautiful, thanks Brent. You hit on everything I wanted to know.
Hello @zy021511,
Generally speaking, if you have objects within a display group that you need to change/edit/remove specifically, you should create a local way to access them… either a local variable, a reference within a table, etc. Although you could technically access the item by its “index” within the display group, it could easily get shifted around if you put other items in the group and move their z-index order around. Thus, to be safe, you should create a dedicated reference to the object and always use that to effect changes on it.
Regards,
Brent
Curious to hear Brents take on this technique…
Hey zy, one thing you can do to keep “handy” access to objects in a group you want to modify later is to include a pointer to them inside the group where they exist.
So to modify an object inside a group later, you could store a pointer to it inside the group where it was inserted, as so
[lua]
local g = display.newGroup()
local myRect = display.newRect(0,0,100,100)
g:insert(myRect)
g.myRect = myRect – Save a pointer to it the code can access later
–
– Later, code anywhere in your app can access the object via
–
g.myRect:toFront()
g.myRect.alpha = 0.5
[/lua]
Sure, that should be fine. The caution is that by placing a reference there, it needs to be removed along with the object. But, I guess that’s really not any different than removing an external reference to the object… just a different pointer to it.
The other caution would be if an object moved groups, suddenly the previous group would have a reference to an object that is no longer inside it.
Personally, I prefer just keeping references external. Easier to track IMHO.
Brent
Thank you guys, I fix the problem.
I add point to the display group.
Thank you guys very much.
OK, sounds good - wanted to make sure there wasn’t any conflict with how the sdk processes groups if we stored our own pointers / data in there.
Also, I think the memory management takes care of itself this way… As long as you *don’t* store a pointer to your object somehwere else (ie; it’s original pointer created as a local as above, so the reference disappears at end of scope) then the pointer in the group is considered unused once (pointers to) the group it exists in is unused / removed / nil’ed.
At least that’s how it seems to work from here.
@mpappas, you’re correct… and just to clarify (as you probably already know), there are some restrictions on display groups, meaning, they are tables, but their children can’t always be accessed in the same ways as you might access children of normal tables… no ipairs() and no table.insert() into display groups.
Otherwise, you can attach properties/references to groups like normal.
Beautiful, thanks Brent. You hit on everything I wanted to know.