Submitted again with this email.
Hmmm, I still don’t see it in the bug tracker and the result screen looks perfectly normal. I’ll have to hit up engineering on this and see what’s happening.
In the mean time, if you could share your .zip file with me and the text you used for the bug report, I can try and file it for you.
Rob
Bug Title: Table View scroll bug
Bug Description: The TableView will generate this Runtime Error when a row is partially off the top of the screen and then the user attempts to scroll the TableView by pressing on the partially exposed row and scrolling the TableView up. Here is an example of the error occurring on the Widget Demo code included with the Corona SDK simulator:
Steps to Reproduce: Launch the Widget demo code. With the Table View selected on the bottom tab, scroll down to about row 15 (don’t scroll down so far that the category row is pinned to the top). Scroll up by pulling down on a partially exposed row at the top of the Table View. If the row is mostly exposed the error does not occur, but if less than half of the row is exposed the Runtime error will pop. See the video link:
Platforms Affected:
Android 5.x
Android 6.x
Corona Windows Simulator
Corona Mac Simulator
Corona Version: 2016.2844
The steps I used to submit the bug report (Chrome): I opened a new tab, typed coronalabs.com into the address bar, selected ‘Forums’ from the ‘Community’ drop down, clicked on ‘Report a bug’ at the top of the page, and then submitted the report (which evidently did not make it to you). The system did not ever ask me to login as I was already logged in on another tab. Hope that helps!
Ed
Case #45528
Thank you Rob!
Sorry if I am missing the obvious, but I can’t find the location on the website where I can track this bug with the case number. Could you point me to the page if it exists?
Thank you, again!
Ed
The bug tracker is internal only.
Rob
Any idea what kind of time frame might be involved in getting this resolved? Days? Weeks? Months?
I’m not looking for an answer that I can use later to be a jerk about, just a guesstimate so I can work around this for the time being.
‘Absolutely No Idea’ is fine if it fits this problem as well.
Thank you Rob!
Ed
It’s hard to tell. It won’t be “days”. I would say weeks or longer. If you can work around it, I would.
Rob
ERROR: Runtime error ?:0: attempt to index field '\_view' (a nil value) stack traceback: ?: in function 'touch' ?: in function \<?:949\> ?: in function \<?:205\>
I have this problem too . Please share me about how to solve this problem . Thank you
Is there more to the error?
It looks like it’s coming from a touch event handler. Perhaps your onRowTouch() function or a button inside of the row created in onRowRender()?
We will need to see some code around those areas. And more from your console log, like the few lines above it.
Rob
Rob,
Just checking in to see if there is an update on this.
Thank you!
No one provided me any additional information.
Rob,
In re-reading your response it is not clear whether you are referring to the bug report above (Case #45528), or to shohoku-boy post.
Thank you.
When you drag off a row in the tableview it’s setting the fill colour on the now unselected row back to the default.
It then turns the separator line back on on the row it’s just uncoloured and the one above
If however the row you’ve just unselected is right at the top of the tableview then the row above it could well have just been culled.
if view.\_rows[self.\_targetRow.index - 1] then if view.\_rows[self.\_targetRow.index - 1].\_view.\_separator then view.\_rows[self.\_targetRow.index - 1].\_view.\_separator.isVisible = true end end
Probably ought to say
-- the row above might have been culled and so not have a view, we ought to care about that if view.\_rows[self.\_targetRow.index - 1] and view.\_rows[self.\_targetRow.index - 1].\_view then if view.\_rows[self.\_targetRow.index - 1].\_view.\_separator then view.\_rows[self.\_targetRow.index - 1].\_view.\_separator.isVisible = true end end
at line 387 in widget_tabelview.lua
(edited my suggested fix after looking for other places it might do the same thing, thought I ought to make it check the same way it does EVERYWHERE else in tableview)
Steve,
Where does one find the widget_tableview.lua file to make the changes you mention? I am not wise to the innerworkings of Corona and a long search of my hard drive did not turn up any results. There were some mentions on the forum of “overriding” the built-in widget library - without any examples of how to go about performing such witchery.
Thank you!
Ed
There are probably proper instructions written by people who know how to do stuff somewhere. I suspect I read them once upon a time when I did it myself and didn’t just guess.
My “don’t really remember and don’t particularly use github” version is something like this
go to https://github.com/coronalabs/framework-widget and press the “download zip” button, that’ll give you a copy of the open sourced version of widget2
copy the widgetLibrary folder from the downloaded zip into your project
Change all the
-- Require needed widget files local \_widget = require( "widget" ) local \_momentumScrolling = require( "widget\_momentumScrolling" )
shaped lines at the top of the files in there to require widgetLibrary.WhateverItsRequiring or you’ll have bits of your widget library and bits of the standard corona one I think.
change the line mentioned in my previous post in widget_tableview.lua,
change wherever you’re requiring widget in your code to require widgetLibrary.widget instead
I don’t think you need any of the other stuff in your downloaded file to make it work, just to override the art assets and themes
Hopefully someone who knows what they’re doing will come along and point out whatever is completely wrong in this post or I’ll look harder at what I’ve actually done with anything else from that download when I’m in the office.
eta: https://forums.coronalabs.com/topic/34183-widgets-20-open-source/ is I think the original instructions but that says to read the readme which seems to not have anything in it.
Rob - any update as to whether this has moved any closer to a fix?