?:0: Attempt To Call Method 'setfillcolor' (A Nil Value)

Solar2D Widgets
#1

 I am using 2013.1076.

I’ve got an app with just a few scenes. When I am in a scene and have a newTableView on the screen and open a pickerwheel over it and close the pickerwheel again, I get an error if I try to move the list in a place that is not covered by rows (not triggering the onRowTouch event).

I get this error:

Runtime error

?:0: attempt to call method ‘setFillColor’ (a nil value)

stack traceback:

        [C]: in function ‘setFillColor’

        ?: in function ‘touch’

        ?: in function <?:683>

        ?: in function <?:218>Handling the unhandled error

The errormessage doesn’t lead me to a place that the problem is occuring. I also scanned my code for the string “setFillColor” and it is not present… Any idea what am I looking at here?

If I first move the list in the newTableView or exit the scene and return to it again, I do not get  this error. Using the touch event of the list and returning to the list, does not help to evade the problem.

#2

At first blush, this sounds like a create / destroy timing related problem…

When you get inputs to objects and destroy them during their own input handler (or called subroutines), you can run into problems. The corona input system fires off multiple events / phases to handlers, and if you destroy the object inside the input handler (or via something called from it), later events/phases that occur for the original object can still be fired off (from the one human touch event).

I’ve got some nested tableViews, and was having a little go-around until I did a few things in my code, starting with making sure the events / phases coming in to my handlers weren’t nil / and other basic checks.

The thorniest part was handling the actual destruction of the tableView itself during it’s own input event… The solution  was to add a delay to tableViews destruction like so:

       timer.performWithDelay( 50, function() showNewGroup(event) end, 1)   – slight delay…                
 

This call has embedded in it a little function that calls the destroy routine (that routine also creates a new tableView for me) but only after a 50 millisecond delay… This allows the input handler time to complete, BEFORE the tableView is destroyed.

I really don’t know if this is your specific problem though – like I said at the top - at first blush it sounds like it, but don’t really know enough about it.

So, my two cents is, do a lot of variable testing, and carpet bomb your input handlers with print statements, especially noting anything that doesn’t look right / is nil…

#3

At first blush, this sounds like a create / destroy timing related problem…

When you get inputs to objects and destroy them during their own input handler (or called subroutines), you can run into problems. The corona input system fires off multiple events / phases to handlers, and if you destroy the object inside the input handler (or via something called from it), later events/phases that occur for the original object can still be fired off (from the one human touch event).

I’ve got some nested tableViews, and was having a little go-around until I did a few things in my code, starting with making sure the events / phases coming in to my handlers weren’t nil / and other basic checks.

The thorniest part was handling the actual destruction of the tableView itself during it’s own input event… The solution  was to add a delay to tableViews destruction like so:

       timer.performWithDelay( 50, function() showNewGroup(event) end, 1)   – slight delay…                
 

This call has embedded in it a little function that calls the destroy routine (that routine also creates a new tableView for me) but only after a 50 millisecond delay… This allows the input handler time to complete, BEFORE the tableView is destroyed.

I really don’t know if this is your specific problem though – like I said at the top - at first blush it sounds like it, but don’t really know enough about it.

So, my two cents is, do a lot of variable testing, and carpet bomb your input handlers with print statements, especially noting anything that doesn’t look right / is nil…

#4

We are experiencing this problem too, after we switched to Widget 2.0 and started implementing iPhone 5 support. The stack trace is short and does not include references to our code, so the problem must be internally in Corona.

@Rob or @Joshua: Can you try to get this fixed in the next build?

#5

Has anyone filed a bug report on this?  We really need one filed.

#6

No reply from Hans if he had any progress resolving his issue (in the case it was a migration to 2.0 issue).

I believe I had a couple issues like this when I first migrated, and hadn’t set the callbacks, new color paramaters, etc, correctly for the new widgets 2.0. (But I presumed hans had migrated to 2.0 completely). But it could just be the new color params aren’t set since they migrated (I think that can also cause the error, the default and over params).

You guys (hans+olav) went through the migration guide, and still getting the error, yes?

Did either of you file a bug report with an example?

#7

I am pretty new at this, but I am still experiencing this problem. The first response from mpappas did not ring a bell for me. I was not doing stuff like that.

I don’t know how to file a bug report. So if someone else could do that…(olavm?)

#8

http://developer.coronalabs.com/content/bug-submission

#9

Has anyone filed a bug on this yet? Basically if you have a tableview and scroll passed the bonds(where there are no rows) it throws this error. Easy to reproduce so easy to make a test case for filing a bug. So if nobody has done it yet I’ll do it, if someone has please post the case number so we can see when its resolved.

#10

I have not filed a bug report, and I don’t think anyone else did, so it would be nice if you would file it.

#11

Had the same issues and other strange behavior with tableview. Rolled back from build .1092 to .1089 and all troubles seems to be gone.

#12

Bug submitted Case number: 23193

#13

Chevol, does this issue occur with the latest daily build?

#14

Yes sir.

#15

We are experiencing this problem too, after we switched to Widget 2.0 and started implementing iPhone 5 support. The stack trace is short and does not include references to our code, so the problem must be internally in Corona.

@Rob or @Joshua: Can you try to get this fixed in the next build?

#16

Has anyone filed a bug report on this?  We really need one filed.

#17

No reply from Hans if he had any progress resolving his issue (in the case it was a migration to 2.0 issue).

I believe I had a couple issues like this when I first migrated, and hadn’t set the callbacks, new color paramaters, etc, correctly for the new widgets 2.0. (But I presumed hans had migrated to 2.0 completely). But it could just be the new color params aren’t set since they migrated (I think that can also cause the error, the default and over params).

You guys (hans+olav) went through the migration guide, and still getting the error, yes?

Did either of you file a bug report with an example?

#18

I am pretty new at this, but I am still experiencing this problem. The first response from mpappas did not ring a bell for me. I was not doing stuff like that.

I don’t know how to file a bug report. So if someone else could do that…(olavm?)

#19

http://developer.coronalabs.com/content/bug-submission

#20

Hey! I have the same problem with the tableview even with the latest daily build. Thanks chevol por making the Bug case number 23193. Have they responded on when it could be resolved?