crash: ?:0: attempt to call method 'setFillColor' (a nil value)

Solar2D General Questions/Discussion
#1

How to trace a bug, if crash reports no meaningful debug info?

12:16:58.025  ERROR: Runtime error

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

12:16:58.025  stack traceback:

12:16:58.025   ?: in function <?:524>

12:16:58.025   ?: in function <?:205>

Happens very often when I press on a row in TableView.

I tried to find in my code possible calls to setFillColor() with nil arguments. Did not found any.

Debug is turned on in build.settings.

Crash happens in Windows corona simulator, and on android devices as well, but with different message:

<long path>/widget/widgetLibrary/widget_tableview.lua:383:attempt to call method ‘setFillColor’ (a nil value)

I think crash occurs when I press on a row and slide finger or mouse pointer a bit, and do it fast enough. 

#2

Can you post line 383?

–InfiSnyp

#3

Sounds like a bug in the tableView library. Can I get you to create a bug report for this please? To do so, create a sample project that demonstrates the issue. It must be a complete project (main.lua, build.settings, config.lua and any other assets needed to build and run the project). Now put that entire project folder into a .zip file. Use the Report a bug feature at the top of the page. After you submit it, you will get an email with a caseID# in the subject of the email. Please post that number back here as a reference.

Thanks

Rob

#4

Just submitted a bug report - Case 45390.

#5

Thanks!

#6

The program submitted possibly could be shorter, but I’m new to Corona, so I made this program from the sample Interface/WidgetDemo. And I did not deleted some lines that are questionable to me. Since when I tried to remove a line

widget.setTheme( “widget_theme_android_holo_dark” )

program failed to start.

#7

This is a completely reproducible problem I’ve been struggling with for some time too. Having spent many hours wrestling with it, I can offer the following advice:

  1. If you can, use the tap event rather than a press/release event. It ONLY happens when your action is defined in the press/release events.

  2. use a timer.performWithDelay on any tableview:reloadData()

I’ve all but eradicated the problem doing the above. But yes, the problem seems to mostly occur on pressing on a row background and then releasing on the scrollview background underneath. As I say, a tap event, if you can get away with it (because obviously it’s limiting compared to the alternatives) eliminates that possibility.

Mind you, I’ve since embarked on a rewrite of the widget2 libraries because frankly they break at the drop of a hat.

If you feel so inclined, another thing I’ve found is worth taking the time to do to avoid a whole raft of potential problems is to tweak scrollviews (and tableviews to a lesser event because they’re written slightly more robustly with at least some basic prevention against self destructing) to not use a transition at all when called with a time of 0 (yes, they call pointless transitions by default whether they need to or not!)

I’ve also taken to manually calling transition cancels (on everything!) whenever I have to delete anything from a scrollview or tableview, because that’s another sure fire way to break stuff.

You shouldn’t have to, of course. But it’s better than the embarrassment of hundreds of reports of run time errors in your business application.

#8

Problem is that I dunno how to detect on what element or part of a table row user clicked. I have a lot of text and color rectangles on each row element, but I can’t add any buttons to row element. And I did not found how to check/read actual X, Y for tap event.

As a workaround I used tap for default action and longer click and hold for select.

About advice. Do I have to do both 1) and 2) or just one of those is enough? Because calling redraw with small delay instead of direct call is not a problem.

#9

i found both to be necessary. It’s actually using tap rather than press/release that made it far more robust. It eliminates any possibility of tableview getting confused about what element it’s supposed to be setting a fill on. Unfortunately, that makes it a little less responsive, because only a particular behaviour is seen as a tap… and it’s people that DON’T tap (but rather linger AND aren’t very good at lifting off in the same place they pressed) that are causing the issue!

#10

I wonder, are we going to have a fix or explanation how to avoid this crash from developers any soon?

#11

Hey there 

Just came across this exact problem.

Could you please post an example of your fixed code?  I tried to implement the delay but it didn’t seem to fix it.  (But I know there are a few ways to skin that cat…)

Thanks heaps

#12

What version are you building with?

#13

Current Daily Build 2016.2907

That said, once you remove the listener the crash goes away… so its a fix but not root cause resolution

To make it work, i inserted a switch widget into each row and name.id the row name so I could refer back to it when dealing with data.

Rock solid.

#14

Can you post line 383?

–InfiSnyp

#15

Sounds like a bug in the tableView library. Can I get you to create a bug report for this please? To do so, create a sample project that demonstrates the issue. It must be a complete project (main.lua, build.settings, config.lua and any other assets needed to build and run the project). Now put that entire project folder into a .zip file. Use the Report a bug feature at the top of the page. After you submit it, you will get an email with a caseID# in the subject of the email. Please post that number back here as a reference.

Thanks

Rob

#16

Just submitted a bug report - Case 45390.

#17

Thanks!

#18

The program submitted possibly could be shorter, but I’m new to Corona, so I made this program from the sample Interface/WidgetDemo. And I did not deleted some lines that are questionable to me. Since when I tried to remove a line

widget.setTheme( “widget_theme_android_holo_dark” )

program failed to start.

#19

This is a completely reproducible problem I’ve been struggling with for some time too. Having spent many hours wrestling with it, I can offer the following advice:

  1. If you can, use the tap event rather than a press/release event. It ONLY happens when your action is defined in the press/release events.

  2. use a timer.performWithDelay on any tableview:reloadData()

I’ve all but eradicated the problem doing the above. But yes, the problem seems to mostly occur on pressing on a row background and then releasing on the scrollview background underneath. As I say, a tap event, if you can get away with it (because obviously it’s limiting compared to the alternatives) eliminates that possibility.

Mind you, I’ve since embarked on a rewrite of the widget2 libraries because frankly they break at the drop of a hat.

If you feel so inclined, another thing I’ve found is worth taking the time to do to avoid a whole raft of potential problems is to tweak scrollviews (and tableviews to a lesser event because they’re written slightly more robustly with at least some basic prevention against self destructing) to not use a transition at all when called with a time of 0 (yes, they call pointless transitions by default whether they need to or not!)

I’ve also taken to manually calling transition cancels (on everything!) whenever I have to delete anything from a scrollview or tableview, because that’s another sure fire way to break stuff.

You shouldn’t have to, of course. But it’s better than the embarrassment of hundreds of reports of run time errors in your business application.

#20

Problem is that I dunno how to detect on what element or part of a table row user clicked. I have a lot of text and color rectangles on each row element, but I can’t add any buttons to row element. And I did not found how to check/read actual X, Y for tap event.

As a workaround I used tap for default action and longer click and hold for select.

About advice. Do I have to do both 1) and 2) or just one of those is enough? Because calling redraw with small delay instead of direct call is not a problem.