Checking for an Object after Group Removed

Solar2D General Questions/Discussion
#1

I am using groups on a screen to hold a series of rectangles and text objects.  I can remove the group from the display by calling the following: -

if BehGrp ~= nil then BehGrp:removeSelf() BehGrp = nil end

This works fine, however I have some code in another function that has to check / remove an object from the group: -

if Overlay ~= nil then Overlay:removeSelf() Overlay = nil end

This code works fine first time around, however when the first function has run the object called Overlay is not set to nil so the second function then tries to remove it (although it has already been removed).

Is there a way of checking if an object has already been removed (e.g. by the group:removeSelf call) as this call does not seem to set all of the objects it holds to nil…

#2

Not the most elegant solution but could you put a true/false flag in the first function then use that conditional in the second function.

T.

#3

Thanks for your reply.  I have once again decided to remove the object before I remove the group.

It does frustrate me that your can this cool functionality in Corona with groups, only that when you use them you have to mop up around them as they are so leaky.

When you remove a group, when would not want to remove the objects that were placed inside the group??  Common sense that is what the functionality should do.

Ho hum, stop moaning now and get back to it…

#4

Groups aren’t really all that fault-tolerant in this way. Your best bet would be to create a table with the objects within it, put the table in a display group, and then delete the table using some nifty code. Something like this:

 local someTable = {} local xRnd = math.random(300) local yRnd = math.random(300) local group = display.newGroup() for i=1, 20 do someTable[i] = display.newRect(0,0,20,20) someTable[i].x = xRnd someTable[i].y = yRnd someTable[i].id = ("someTableNum"..i) group:insert(someTable[i]) print("someTable["..i.."]") end -- after some time... local function cleanItems(obj) local i = 0; print (#obj) for i=#obj,1,-1 do local child = table.remove(obj, i) -- Remove from table if child ~= nil then print ("object deleted = ".. i) display.remove( child ) child = nil end end display.remove( obj ) obj = nil collectgarbage() end cleanItems(someTable)

So here, you’re 1) creating a table, 2) creating objects within this table, 3) randomly placing the objects on the screen, 4) inserting the objects into a group, 5) removing and niling all objects within the table, 6) deleting the table itself and 7) collecting the garbage to complete the chain. 

#5

Hey, thanks for the nifty code.  Kind of doing that.  I suppose my moan is you have the removeSelf method associated with the group.  You call it, it removes the groups from the screen (great), but then leaves all the objects holding on to memory.  So you still have to set them all to nil or other code you have checking for an object being set to nil will fire up.  What is all that about?  It just seems sloppy code putting a method in that only does half a job. 

Anyway, thanks for the code - I will resign myself to hand cranking the removal of the objects very similar to your approach…

#6

It would be nice if CL tied in the above cleaning code when you delete a display group (since they are basically really simple tables) but I am OK with it being on me, so I know exactly what is going on with the objects themselves. Not ideal, but Corona has never been amazing at memory management, so the more I can do myself, to ensure I have that memory back, the better.

#7

Not the most elegant solution but could you put a true/false flag in the first function then use that conditional in the second function.

T.

#8

Thanks for your reply.  I have once again decided to remove the object before I remove the group.

It does frustrate me that your can this cool functionality in Corona with groups, only that when you use them you have to mop up around them as they are so leaky.

When you remove a group, when would not want to remove the objects that were placed inside the group??  Common sense that is what the functionality should do.

Ho hum, stop moaning now and get back to it…

#9

Groups aren’t really all that fault-tolerant in this way. Your best bet would be to create a table with the objects within it, put the table in a display group, and then delete the table using some nifty code. Something like this:

 local someTable = {} local xRnd = math.random(300) local yRnd = math.random(300) local group = display.newGroup() for i=1, 20 do someTable[i] = display.newRect(0,0,20,20) someTable[i].x = xRnd someTable[i].y = yRnd someTable[i].id = ("someTableNum"..i) group:insert(someTable[i]) print("someTable["..i.."]") end -- after some time... local function cleanItems(obj) local i = 0; print (#obj) for i=#obj,1,-1 do local child = table.remove(obj, i) -- Remove from table if child ~= nil then print ("object deleted = ".. i) display.remove( child ) child = nil end end display.remove( obj ) obj = nil collectgarbage() end cleanItems(someTable)

So here, you’re 1) creating a table, 2) creating objects within this table, 3) randomly placing the objects on the screen, 4) inserting the objects into a group, 5) removing and niling all objects within the table, 6) deleting the table itself and 7) collecting the garbage to complete the chain. 

#10

Hey, thanks for the nifty code.  Kind of doing that.  I suppose my moan is you have the removeSelf method associated with the group.  You call it, it removes the groups from the screen (great), but then leaves all the objects holding on to memory.  So you still have to set them all to nil or other code you have checking for an object being set to nil will fire up.  What is all that about?  It just seems sloppy code putting a method in that only does half a job. 

Anyway, thanks for the code - I will resign myself to hand cranking the removal of the objects very similar to your approach…

#11

It would be nice if CL tied in the above cleaning code when you delete a display group (since they are basically really simple tables) but I am OK with it being on me, so I know exactly what is going on with the objects themselves. Not ideal, but Corona has never been amazing at memory management, so the more I can do myself, to ensure I have that memory back, the better.