Hi Brent
In fact I don’t observe any snapping back. And when there’s no snapping, the value for that column returned is nil :(
Any workaround?
We’re investigating the possible snap-back issue now. I do get snap-back in most cases using the latest build, but sometimes it doesn’t snap back (in the instance I described in my last post). We’re investigating the cause of this now. So, there’s not a workaround at the moment…
Best regards,
Brent
Is the current code, from the newest build, the same as in the github repository: https://github.com/coronalabs/framework-widgets/blob/master/widgetLibrary/widget_pickerWheel.lua ? If it is, I could probably spend some time on it as well 
(I was advocating hard the use of Corona for the app [medical application], instead of other options, and it really kicked my ass now ;)
Hi @kender,
That repo version is not the most current, but you can explore its methods if you wish. One thing about picker wheel (and it’s rather tricky to find a resolution for) is when the user drags outside of the wheel’s “bounds”, thus not triggering an ended/cancelled phase… so the column doesn’t know if/when to snap back in that case. We’re pondering various solutions for this.
Brent
Well, I’m getting snapping for a moment, then it stops…
Here’s the video: https://dl.dropboxusercontent.com/u/51630060/pickerWheelNotSnapping.mp4
Gonna debug it with the code from github, if there’s no way to get my hands on the most current version :)
I’m having the exact same issue and the problem with the picker wheel happens in both the simulator and in builds on my device. If user drags mouse or slides their finger, the wheel doesn’t snap to the nearest value making it pretty much impossible to select a value from the wheel using these methods (the values can’t be read when the wheel doesn’t snap into position). However, if the user clicks or taps on a value, the wheel correctly scrolls to the correct position and the value can be read programatically with no problem at all.
If I could read any value at all from it I could force it to snap to the nearest whole number, but that isn’t possible.
Verified that the issue is still there with the latest daily build (#1260) using the widget demo sample app. If you give the picker a fast spin it comes to stop and snaps to place. If you move the picker and let it go right above the line it doesn’t snap. Its almost as if it can’t decide which way to snap so it goes nowhere… See attached screen capture. Thanks for your attention.
So, a question raises - is it realistic to believe that this issue would be fixed soon (like, in a couple of days)? If not, is it possible to release the current, most recent version of widgets code to github, so maybe “outside world” could fix that bug?
So, I decided that I need to do something with it. The project couldn’t really wait too long 
Since I needed the values read from the picker, but the “snapping” behaviour wasn’t that critical, I implemented a simple fix that returned me the values even if the rows weren’t aligned perfectly.
I used the github version of Widgets 2.0 (https://github.com/coronalabs/framework-widgets-legacy).
I needed to modify the view:_getValues () function to handle the nil-value issue, so now it looks like this:
-- Function to retrieve the column values function view:\_getValues() local values = {} -- Loop through all the columns and retrieve the values for i = 1, #self.\_columns do print ( i, self.\_columns[i].\_values ) values[i] = self.\_columns[i].\_values if values[i] == nil then values[i] = getNearestValueForColumn ( i ) end end return values end
And the getNearestValueForColumn ( i ) function is something I added at the top of the file:
local function getNearestValueForColumn ( columnIndex ) local cp = viewColumns[columnIndex]:getContentPosition () local rh = 40 -- row height local y1, y2 = viewColumns[columnIndex].contentHeight / 2 - rh / 2, viewColumns[columnIndex].contentHeight / 2 + rh / 2 local y\_mid = viewColumns[columnIndex].contentHeight / 2 local pos = cp local idx = 1 local idxFound = nil local dist = 100000 for idx = 1, viewColumns[columnIndex]:getNumRows () do local pos = cp + ( idx - 0.25 ) \* rh local d = math.abs ( pos - viewColumns[columnIndex].contentHeight / 2 ) if d \< dist then idxFound = idx dist = d end end idx = idxFound print ( "Row idx: ", idx ) local phase = "release" -- print ( "Did tap", phase) local row = { index = idx, value = opt.columnData[columnIndex].labels[idx] } return row end
Now the picker doesn’t snap nicely, so this isn’t fixed (I tried to achieve that too, but my solution was messing something else up; maybe I’ll get back to this if time allows) but at least the values can be read from the rows.
Hope this can help anyone
Just tried WidgetDemo in #2076 and this issue seems to be fixed.! Good work.
Nope. The snapping is still not consistent. This still needs work.
Over a year since the last comment, and this one is still an issue (tested in 2015.2596). Since I don’t think anybody mentioned alternative workarounds to fixing the widget itself, here’s what I’m using to not crash when it happens:
[lua]local values = datePicker:getValues()
– CORONA BUG: Sometimes the values can be nil.
– This happens when one of the tables stopped scrolling but hasn’t “snapped” to a selected index.
– Prompt the user to fix the bad column.
if not values[1] then
native.showAlert(“Error”, “Please make sure a month is selected.”, {“OK”})
elseif not values[2] then
native.showAlert(“Error”, “Please make sure a day is selected.”, {“OK”})
elseif not values[3] then
native.showAlert(“Error”, “Please make sure a year is selected.”, {“OK”})
else
– Do whatever you want with the date now.
end[/lua]
Then, hopefully the user is smart enough to pretty much just touch the offending column, getting it to snap to a valid index.
Hi @mark.sandell,
To update this case somewhat, can you describe exactly what is occurring? Does the column occasionally never snap into place? Or does it snap into place but occasionally yields a nil value? Or are you trying to get the value while the column is currently adjusting to the snap position (as in, that short time when the user lets up but the row needs to snap into place) ?
Best regards,
Brent
Hi Brent! Correct, the column occasionally never snaps into place. It will completely stop moving, but no index is selected, and therefore none of the labels in the “bad” column are highlighted in a bold/darker font, unlike when one is selected.
I have used getValues() while the column is still moving. This has been fine for me, as getValues() simply returns the last selected items. It’s only when everything stops moving and yet one column is still not snapped to that you get a nil value for any “bad” column. Any “snapped-to” columns will still return valid data in this case, so you’ll likely just get one nil entry.
To say that in a different way, values = pickerWheel:getValues() always returns a valid table for me, but values[1], for example, might be nil.
I hope that helps clarify it! I don’t have exact repro steps, but if I tap and drag around on the picker widget columns for a bit, I’ve typically been able to get it into this state within 30 seconds to a minute.
Hi Mark,
I thought we worked out most of the oddities with this over time, and especially with the most recent set up updates to the widget library, however you say it’s still occurring. I’d like to assist you, but it’s going to be very difficult without knowing how/when this occurs, and what triggers the non-snap. Is there any way you can clarify when it occurs? The picker wheel is an especially complex beast, mechanically, so I need some starting point to begin attempting to repro the issue.
Thanks,
Brent
Thanks, Brent. To start, I would recommend taking the example Picker Widget code from Corona (the one that does a simplified date picker with the months, days 1-31, and the year). I’ll work with the year column for my debugging. I’ve found it easiest to reproduce on my iPhone, since dragging the picker wheel on my laptop’s mouse pad isn’t the easiest. I have gotten it in the simulator, but it’s kinda hard.
Now, there are actually two bugs that I’ve noticed just now while trying to debug this, and maybe they’re related. Here’s the first, where the wheel has stopped spinning and has a valid selection, but note that the selected year column (2009) is not centered within the middle blue bar like a selected column should be. In this case, getValues() is completely valid and matches the black items (October 30, 2009).
The second is the issue I described in my above post, but no item is selected in the column. It’ll look like the image below – everything has stopped scrolling and the column may or may not be centered on a year – but no year will be in the black “selected” font, and getValues returns nil for the third (year) column. It’s probably no help, but I’ve noticed when this bug occurs, the table seems to start scrolling the one direction you scrolled, then jumps back the other direction for no apparent reason.
Here’s what I did to reproduce this:
- Scroll down on the year column. While it’s scrolling, tap the year column.
- Scroll up on the year column. While it’s scrolling, tap the year column.
- Repeat some combination of 1 and 2 until nothing is selected when you tap.
Since I know these repro steps really stink, I’d be happy to try gathering more data from the widget’s private variables if you have any suggestions on what values to grab might be useful. On the off chance I can reproduce this in the debugger (I’ll give it a try tonight), maybe I can leave it running and give you a shout to see what info you might be able to grab from there.
I’m not sure if this helps at all, but I wrote up a (very primitive) method to basically dump most of the attributes of the picker wheel to the terminal when you press a button. If you diff the output from a good selection and a bad selection, I think these are the critical differences:
On the bad selection:
- wheel._view._columns.3._view._moveDirection = vertical (good = nil)
- Does this mean it thinks the column is still moving?
- wheel._view._columns.3._view._prevY = -2223.5 (good = 0)
On the good selection (the bad selection is nil for all of these):
- wheel._view._columns.3._values._label = 1950
- wheel._view._columns.3._values.id = 3
- wheel._view._columns.3._values.index = 66
- wheel._view._columns.3._values.isCategory = false
- wheel._view._columns.3._values.value = 1950
Alright, I had a bit more luck narrowing down a repro case for this today! On my phone, if I try to scroll by doing a really small drag on one of the columns right around the lower or upper edges of the widget, it tends to hit this bug much more frequently. Hope that helps!
hey guys.
@mark.sandell: if you got a repro case, could you please file a bug and paste back the number?
Thanks!
alex
alexf, I’ve filed a report as requested: Case 40036