oh, Alex, your link of new fixes has a period at the end…making it broken…may want to fix that…
anybody else running into this with the newScrollView in v2189
attempt to perform arithmetic on field ‘_oldAnchorX’ (a nil value)
?: in function ‘_calculatePosition’
I had that when I included some widget sources in a subfolder or under a different file name. Basicaly that happens when you require your own widget.lua version that has a different name say mywidget.lua or is in a subfolder, however the widgets themselves (say scroll view) also require widgets.lua (this will be the built in one) in their code. If this files are not the same one then you get the error you mentioned. To fix it either move your widget.lua to the root project dir or you will have to include all the widget files that you use and fix the require statements in them. Scroll view for example would need widget.lua, widget_scrollview.lua and widget_momentumscrolling.lua.
Thanks for the updates.
Tableview is still showing strange behaviour when adding / deleting rows with the padding on top / bottom.
Scrollview is still a bit sloppy when scrolling from the top or the bottom.
The scrollbar sometimes goes beyond the limit and then positions at the right place when the content is scrolled to the end.
Do you know when this issues will / can be fixed?
Thanks,
Roman
@searchm The jump back while scrolling again during bounce back is not fixed yet. You can use the fixes I posted on GitHub if you need that fixed right away. I posted the link in another thread here in widgets forum. Nothing was changed about the scroll bar also. Regarding that can you come up with a small sample that shows that and post the code so I can look at it and maybe I can include the fix on GitHub.
Also what are you seeing wrong when inserting or deleting rows with padding?
@primoz (or anyone else patching widgets)
do you have any interest (or estimate for level of effort) to modify widgets so that newPickerWheel will scale properly for a 640x960 content area?? Someone said he thought it might only be a matter of upsizing the images but I’m a bit suspicious of that as I’ve not seen any code where the math is based on the loaded image-sizes. I’m hoping someone who’s spent more time in the widget code than me can give me encouragement or a healthy dose of terror 
Unfortunately I have never dealt with the picker wheel source so I coud not tell you off the top of my head but I can take a look at it in the evening.
@primoz,
I think I logged a bug for the issue that @searchm was speaking of a while back (and @searchm, please correct me if I am wrong about what you were explaining) about the scroll bar jumping when hitting the bottom of the scrollable area.
This is the sample code that I had uploaded to the bug:
https://drive.google.com/file/d/0B8BC-52RZvXoSXhURm5HSl9tNlk/edit?usp=sharing
thanks for your effort. already downloaded your code couple of days ago, but I haven’t checked it out yet. I will do that later.
will check it out later.
Here are two videos.
Video 1
Add some rows and start to scroll the content, you will see that there is some padding that wasn’t there before. means that you are able to scroll even though the content is smaller then the whole widget height.
Video 2
The same thing, only reloaded. Now the padding has disappeared, but when you delete rows and start to scroll, there is some weird behaviour / padding issue.
To speak of my frustration which is gathering since 2 years that I’m using Corona widgets:
I wouldn’t even dare to release code, which is so buggy to the public. Especially not when I get paid for that.
Seems like you spend zero time testing it in a realistic environment before releasing it.
In two years I could neither use the tableView nor the scrollView widget fearless / uncritical / unhesitating the way it is.
Well the content is always scrollable even if there is only one row. If you don’t want that then you have to check it yourself and use setIsLocked(true).
The issues in the videos are I believe caused by either setting scrollHeight that is smaller than the widget height or manually repositioning row.view.y. You should not do that. I have never needed to set scrollHeight in tableView or ScrollView beacuse they handle it by themselves in respect of the content. If you need to set a specific scrollHeight even though there is no content there or you want to set it smaller than the content then you would need to call it but I think there were some issues there. I have not tried. Regardless of what you need you should never set scroll height that is smaller than the widget height.
Let me know if this is the case.
thanks for your help.
Unfortunately that’s not the case. I’m not setting scrollHeight anywhere.
I’m aware that the tableView is always scrolling unless I disable it.
The issue in the video is not that it’s scrolling but that it’s having some padding on top or on the bottom after adding new rows which doesn’t belong there. This becomes obvious when you try to scroll the content after adding new rows.
As far as I know is Alex currently working on this bugs and the fixes should be available soon.
I have seen that. As I’ve said I’ve seen that happen when setting wrong scroll height or moving the table rows manualy. I see that table view actually doesn’t have setScrollHeight so that can’t be it. Are you by any chance changing the rows y position manualy or anything like that?
Do you set any bottom or top padding?
Could you make a small sample that shows this?
nope, nothing that you suggested. The widget’s just buggy. that’s all.
– Create a tableView
tableView = widget.newTableView
{
top = layout.contentY,
width = layout.screenWidth,
height = layout.screenHeight - layout.contentY,
listener = tableViewListener,
onRowRender = onRowRender,
onRowTouch = onRowTouch,
hideBackground = true
}
tableView.anchorX = 0.5
tableView.anchorY = 0
tableView.y = layout.contentY
group:insert( tableView )
Well that is not enough to show the bug. I or Alex if he wants to fix this would need a full working sample that shows this problem.
I think i know what’s going on, and we have a similar case on file. Nevertheless, a complete sample showing the issue would come in very handy (posted as a bug report, please).
We have scrollview/tableview scrolling fixes in the works atm. Those should fix the weird behavior searchm exposes here.
alex
Hey alex,
excellent news. thanks. Really need this fixes till mid / end next week. I will try to fill a bug report for you.
@searchm: Thanks, that would be great because i can run it through the codebase and see if your issue gets fixed.
alex