How to remove all touch event listeners of certain flavor from a group of display objects

#1

Hi, I was hoping someone might be able to help me with this.

I have a group of display objects stored in an table called grid[x][y]
when a player clicks on a move option, depending on certain factors, I assign 1 of 3 different touch listeners to the surrounding display objects, but not all the display objects.

What is happening is that if the player does not complete the action by touching on one of these surrounding display objects, but instead, selects a totally unrelated display object, I want to cancel the previously assigned touch listeners.

I know that I can use removeEventListener(“touch”, myfunctionNames) for each specifically assigned listener, but what I want is to be able to remove all touch events of a particular flavor instead of rerunning the process I used to assign the specific listeners in the first place.

So is there a way to say removeEventListener(“touch”, onMoveTouch) that will then remove any and all touch listeners tied to the onMoveTouch function?

The reason I want to do this is because the first time, and many times actually that my function onTileTouch gets called, and where I need to cancel these listeners, these specific 3 flavors of additional touch listeners may not even exist, and often, only 1 of these touch listeners will exist.

So I just want to check if they exist, if they do, remove them and then check for the next type to be removed, etc.

If that is confusing, I can post specific code.

thanks [import]uid: 170004 topic_id: 35982 reply_id: 335982[/import]

#2

Hi @tbernard,
I wonder, could you simplify this by just keeping a touch listener on every grid object, and just changing its “type” via another property on the object, like “object.touchType = “explode”” or something? You could then use a common touch handler for all objects, with conditional logic within that determines what “type” was touched.

I just worry that a constant add and remove routine will get unruly, and lead to memory leaks unless you are extremely careful how you’re managing it all.

Best of luck,
Brent [import]uid: 200026 topic_id: 35982 reply_id: 143075[/import]

#3

Hi Brent
That is pretty much the solution I came up with last night while sleeping on it. :slight_smile:

I’ll try and get that implemented today.

Thank you [import]uid: 170004 topic_id: 35982 reply_id: 143083[/import]

#4

ouch. Just spent a few hours tearing my hair out over making this change, and then making it work.
kept getting more then 60 upvalues error and couldn’t figure out why.
Turns out I must be up against the wall for variables, because after I reworked another area of code and got rid of a few, my new variables worked just fine.

Now I have to figure out how, and what to move into modules to make a little more breathing room.

But, it now works like I needed it to, so thanks again Brent [import]uid: 170004 topic_id: 35982 reply_id: 143114[/import]

#5

Great to hear! A useful way to overcome the “upvalues” limit is to just tuck those individual tables/variables into a separate containing table. It’s also a nice way to manage and keep track of variables.

Brent [import]uid: 200026 topic_id: 35982 reply_id: 143118[/import]

#6

Hi @tbernard,
I wonder, could you simplify this by just keeping a touch listener on every grid object, and just changing its “type” via another property on the object, like “object.touchType = “explode”” or something? You could then use a common touch handler for all objects, with conditional logic within that determines what “type” was touched.

I just worry that a constant add and remove routine will get unruly, and lead to memory leaks unless you are extremely careful how you’re managing it all.

Best of luck,
Brent [import]uid: 200026 topic_id: 35982 reply_id: 143075[/import]

#7

Hi Brent
That is pretty much the solution I came up with last night while sleeping on it. :slight_smile:

I’ll try and get that implemented today.

Thank you [import]uid: 170004 topic_id: 35982 reply_id: 143083[/import]

#8

ouch. Just spent a few hours tearing my hair out over making this change, and then making it work.
kept getting more then 60 upvalues error and couldn’t figure out why.
Turns out I must be up against the wall for variables, because after I reworked another area of code and got rid of a few, my new variables worked just fine.

Now I have to figure out how, and what to move into modules to make a little more breathing room.

But, it now works like I needed it to, so thanks again Brent [import]uid: 170004 topic_id: 35982 reply_id: 143114[/import]

#9

Great to hear! A useful way to overcome the “upvalues” limit is to just tuck those individual tables/variables into a separate containing table. It’s also a nice way to manage and keep track of variables.

Brent [import]uid: 200026 topic_id: 35982 reply_id: 143118[/import]

#10

Hi @tbernard,
I wonder, could you simplify this by just keeping a touch listener on every grid object, and just changing its “type” via another property on the object, like “object.touchType = “explode”” or something? You could then use a common touch handler for all objects, with conditional logic within that determines what “type” was touched.

I just worry that a constant add and remove routine will get unruly, and lead to memory leaks unless you are extremely careful how you’re managing it all.

Best of luck,
Brent [import]uid: 200026 topic_id: 35982 reply_id: 143075[/import]

#11

Hi Brent
That is pretty much the solution I came up with last night while sleeping on it. :slight_smile:

I’ll try and get that implemented today.

Thank you [import]uid: 170004 topic_id: 35982 reply_id: 143083[/import]

#12

ouch. Just spent a few hours tearing my hair out over making this change, and then making it work.
kept getting more then 60 upvalues error and couldn’t figure out why.
Turns out I must be up against the wall for variables, because after I reworked another area of code and got rid of a few, my new variables worked just fine.

Now I have to figure out how, and what to move into modules to make a little more breathing room.

But, it now works like I needed it to, so thanks again Brent [import]uid: 170004 topic_id: 35982 reply_id: 143114[/import]

#13

Great to hear! A useful way to overcome the “upvalues” limit is to just tuck those individual tables/variables into a separate containing table. It’s also a nice way to manage and keep track of variables.

Brent [import]uid: 200026 topic_id: 35982 reply_id: 143118[/import]

#14

Hi @tbernard,
I wonder, could you simplify this by just keeping a touch listener on every grid object, and just changing its “type” via another property on the object, like “object.touchType = “explode”” or something? You could then use a common touch handler for all objects, with conditional logic within that determines what “type” was touched.

I just worry that a constant add and remove routine will get unruly, and lead to memory leaks unless you are extremely careful how you’re managing it all.

Best of luck,
Brent [import]uid: 200026 topic_id: 35982 reply_id: 143075[/import]

#15

Hi Brent
That is pretty much the solution I came up with last night while sleeping on it. :slight_smile:

I’ll try and get that implemented today.

Thank you [import]uid: 170004 topic_id: 35982 reply_id: 143083[/import]

#16

ouch. Just spent a few hours tearing my hair out over making this change, and then making it work.
kept getting more then 60 upvalues error and couldn’t figure out why.
Turns out I must be up against the wall for variables, because after I reworked another area of code and got rid of a few, my new variables worked just fine.

Now I have to figure out how, and what to move into modules to make a little more breathing room.

But, it now works like I needed it to, so thanks again Brent [import]uid: 170004 topic_id: 35982 reply_id: 143114[/import]

#17

Great to hear! A useful way to overcome the “upvalues” limit is to just tuck those individual tables/variables into a separate containing table. It’s also a nice way to manage and keep track of variables.

Brent [import]uid: 200026 topic_id: 35982 reply_id: 143118[/import]