seeing extra 'touch' with tableview

Audio and Graphics
#1

Hi,

TL;DR: my (invisible) tableview gets spurious onRowTouch invocations when I tap on a button *and* the button handler then makes the tableview visible.

I’ve got a tableview. tv_list, that occupies about 2/3 of the screen (16 rows of 2 lines of text).

When I tap on a row, I set the tableview to invisible (tv_list.isVisible = false),

and display three buttons … buttons that happen to be within the same screen area as the rectangle of the now invisible tableview.

(“display”: I set the three previously created buttons to “isVisible = true”)

Each of the three buttons has an “onRelease” handler.

Each handler is of the form:  if event == “ended” … do some work… end; return true

Two of the buttons work fine.

The third button is odd … about 80% of the time when I tap it (on the simulator), the handler

is invoked, and exits.  *THEN*, the tableview’s onRowTouch handler gets invoked!

I’ve tried making not only the tableView object invisible, but also the newRect and newText objects that I created in it (from onRowRender) inVisible … that extra invisibility doesn’t change things.

The three buttons handlers are nearly the same.

If I swap the position of any of the three buttons, the problem moves to the new location of the original bad button (i.e., it’s not just screen position related, but handler related).

The handler that has the problem does about 60 Corona “API” calls (i.e., setting objects

to isVisible = true (or false), as appropriate). 

This one statement triggers the ‘bounce’ (erroneous call to onRowTouch):

   tv_list.isVisible = true

It’s as if the underlying Corona code is (incorrectly) saying “since the tableview is now visible, and we’re processing a tap that would be within it, queue up the tap event for the tableview’s touch handler”.

Any suggestions?   

(Yes, every event handler ends with “return true”.)

(Yes, the next step would be to bundle up the app and upload it, I was hoping to avoid that for now.)

I have worked around the problem, but … I don’t like kludges :slight_smile:

The workaround:

   - in the button handler, just before ‘return true’, I added:   cancel_time = system.getTimer ()

   - in onRowTouch handler, at start, I added:  if (system.getTimer () - cancel_time) < 10 then return true; end

…which works.

(The visible/invisible stuff is my version of director/scenes.)

thanks,

Stan

#2

Hey Stan,

I think people are going to be reluctant to bite into this because it is visually hard to decipher.  Adding some formatting to the code  with the <> button would help and maybe grouping things together if it makes sense - usually people make things hard to read because there is not enough white space.  In this post however, there is an over abundance of white space chunking like elements together and formatting the code might get you some more bites.

#3

@sporkfin, thanks … I understand your point, and I had thought about it.  In this case, while I was writing it, I thought the description of what I was doing probably more important than the code.  And, indeed, it led me to the single line that triggers the problem (using “isVisible”), and the conjecture as to the likely bug behind the symptoms.  (Not the first bug I’ve found with the “isVisible” support :slight_smile:

I’m putting together a tiny project to try to reproduce this.

thanks again,

Stan

#4

I’ve submitted an official bug report, along with a project to duplicate the problem(s).

(For the curious, www.sieler.com/corona/bug_tv.zip and/or …/bug_tv.apk)

#5

Hey Stan,

I think people are going to be reluctant to bite into this because it is visually hard to decipher.  Adding some formatting to the code  with the <> button would help and maybe grouping things together if it makes sense - usually people make things hard to read because there is not enough white space.  In this post however, there is an over abundance of white space chunking like elements together and formatting the code might get you some more bites.

#6

@sporkfin, thanks … I understand your point, and I had thought about it.  In this case, while I was writing it, I thought the description of what I was doing probably more important than the code.  And, indeed, it led me to the single line that triggers the problem (using “isVisible”), and the conjecture as to the likely bug behind the symptoms.  (Not the first bug I’ve found with the “isVisible” support :slight_smile:

I’m putting together a tiny project to try to reproduce this.

thanks again,

Stan

#7

I’ve submitted an official bug report, along with a project to duplicate the problem(s).

(For the curious, www.sieler.com/corona/bug_tv.zip and/or …/bug_tv.apk)