@searchm: We are aware of it, and working on completely fixing it.
alex
@alexf I can tell you exactly where the problem is. If you need it just give me a shout, I’ll be glad to help.
I also noticed that if the scrollview position is scrolled up (the position is negative). Horizontal scrolling disabled. If you scroll now to a positive value and lift the finger the scrollview moves automatically back to 0 as expected. If you scroll up during this automatic transition (from positiv to zero) the scrollview moves a bit and if the transition would be over it jumpes during the new transition back to zero for a moment. That generates a very unflowing feel.
Hope it become clear what I mean 
@sunmills: I believe you make a clear explanation. We already have a similar report which i’m looking at, i’ll include your observations into the testing.
@primoz.cerar: Always open to communication. PM-ed you.
alex
Alex…
Thanks for all the great work on the widgets!
And don’t do this if you believe it will cause any regression, but would you look at whether you believe the scrollView should perform callback to it’s event listener during “bounce” and “scrollToPosition” phases as well. Right now, it only makes the callback in relation to actual “touch” (manual) events. This improvement will allow us to better keep native objects in-position without resorting to heavy-handed tactics. Adding “bounce” and “scrollTo” phases would be enough for anyone who’s worked around the prior omission to ignore the new more uniform callbacks.
Much appreciation!
D
Great idea!
Any new on when this might be ?
Soon.
Any idea when bug 30464 - scrollView issues: scrollbar jumps, scrollbar cut off at top might get looked at?
Since the issues are also in 2100, I understand they won’t make it in the public build, but they have not been fixed along with the other scrollView issues that were recently addressed, so just wondering when they might get some attention.
Thanks!
object:scrollTo( “bottom” ) seems to scroll to the bottom but place the bottom in the center of the scrollview, not at the bottom of the area as it should. Perhaps there is an anchoring issue, but I can’t find docs for this! Help!
@mimetic I have notice this also but I changed it so I don’t use it. I also thought it might be an anchor issue.
I’m a bit surprised, that the new public build is already released. Does this mean that all mentioned widget bugs are fixed as announced for the upcoming public build?
@sunmills: All the included fixes are here: https://developer.coronalabs.com/content/corona-sdk-release-notes-build-2014-2189.
@alexf now that the public build is released could you please update the github repository for widgets. I really need to merge my modifications with the new source before moving to the new build.
Thank you
Great news. Sorry to annoy you about this but i really need it before I move to the new build.
Thank you.
You’re not annoying at all.
With pleasure!
alex
Thanks very much for the fixes Alex…
has anyone patched “newPickerWheel” to scale properly on 640 x 960?? If not, does anyone have ideas on how to do it? That’s something I’ll need done in the next month or so and would love it if it’s already been accomplished.
Also, many months ago Rob made (what I thought was) an excellent suggestion about us standardizing on 1800x1200 content-area in config.lua. It’s a nice clean, highly granular and easily divisible set of dimensions. If that is to be the official, recommended “best practice”, then is there any plan to make the widgets either scale or default to those dimensions.