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

[JWiow]

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!

[nick1024]

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

[bluetardis]

@JWiow

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.

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

[rob]

What version are you building with?

[bluetardis]

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.