widget.newPickerWheel selected rows issue

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:

  1. Scroll down on the year column. While it’s scrolling, tap the year column.
  2. Scroll up on the year column. While it’s scrolling, tap the year column.
  3. 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

Did anyone ever figure this one out? I’m still having this problem with the latest daily build (2015.2697).

If I release my finger just off screen then the picker wheel scrolls back but the selected value doesn’t highlight and I get a returned value of nil when trying to get the value.

Thanks,

Ian

Hi Ian,

Does this occur in the Corona widget demo on your device(s)? I just tested it on iPhone 5 and it works fine… releasing outside the screen lets the picker scroll to the value, and that value highlights.

Please run a few tests on this project to confirm whether it’s a picker wheel issue or an issue with your code:

https://github.com/coronalabs/samples-coronasdk/tree/master/Interface/WidgetDemo

(this is the same sample that’s located in your local Corona SDK application folder, so you can test however is most convenient).

Brent

Hi Brent,

It seems it happens when in landscape mode. I couldn’t get your demo to do it in it’s natural portrait mode, but when I switched to landscape, if you release outside the edge of the screen on the simulator or device, sometimes it happens (not always). I’ve attached a screenshot.

As you can see, the month is not highlighted black, despite having slotted back into the right position.

Thanks,

Ian

WidgetPickerError.png

Hi Ian,

I still can’t reproduce this, even in landscape mode on either Simulator or device (iPhone 5). What “percentage” of times are you getting it to occur? Which side of the screen do you release on when it happens? Every time I drag off the screen in any direction, the OS recognizes that the touch has ended and the picker slides to its nearest value and the value highlights.

Brent

Hi Brent,

I can probably recreate it 1 in 5 times. I’m selecting the left column, dragging down off the simulator and releasing. Mostly it pings back fine, but every now and then the item isn’t selected. It’s always going to the right place, just not changing colour.

Thanks,

Ian

Hi Ian,

Sorry, but I still can’t reproduce this… I tried about 30 times and it never occurred. This was using our WidgetDemo in “landscapeLeft” mode, dragging down on the first column, off the Simulator view, and releasing. Can you assemble a video recording of your scenario so I can see how it’s happening?

Brent

Okay - I’ve got it on video. What’s the best way to send it to you?

I did reinstall Corona and now I can only get it to happen every 50 times or so. Not sure why the sudden difference as I had the latest build installed before that too.

Hi Ian,

Unless this sample must remain “private” (asset/idea protection or whatever), can you just put it up on Dropbox or even on YouTube/Vimeo?

Thanks,

Brent

Okay I’ve e-mailed you the link.

Cheers.

Hi Ian,

I guess I never asked this, but can you manage to reproduce this on an actual device? I was able to get it to occur in the Simulator, but most crucially is whether you can get it to happen on a device. Obviously, the Simulator is and always has been a “close as possible” emulation of a real device. While you can drag outside the Simulator’s bounds and still get touch responses, on a device that’s impossible (you can’t get a response by dragging your finger off the device into mid-air). That might be a factor in all of this.

Thanks,

Brent

Did anyone ever figure this one out? I’m still having this problem with the latest daily build (2015.2697).

If I release my finger just off screen then the picker wheel scrolls back but the selected value doesn’t highlight and I get a returned value of nil when trying to get the value.

Thanks,

Ian