The PickerWheel is far from fixed.

After filing a bug request way back at the end of 2011, imagine my joy reading

[text]Post date:
Sat, 2012-07-28 09:58
Release notes for build 2012.867 through 2012.868

Widget: Fixes casenums 15980, 15840 (picker soft-landing bug), and casenums 15550, 15871 (scrollview events bug). [/text]

Which part has been fixed?? Certainly not the soft landing.
You can still select between two values and the picker wheel will stay there.

It does not tick up or down to the next value(soft land), it stays in between two values.

Please don’t say submit a bug report as it took 7 months for the last one to be looked at and then it was closed before even being properly fixed.

I have tested the windows, mac version AND compiled to iphone. Definitely not fixed, so still having to write client apps in 2011.644 (the last build before widget change) if you require a picker wheel with custom columns. Obviously this is not a great move if you need to compile for Ipad3.

My license is due for renewal in the next couple of months and I would like to still use corona, so it would be good to have this fixed before I need to make that decision. Corona is good, but no longer on its own in this field!

[import]uid: 103163 topic_id: 29498 reply_id: 329498[/import]

I just rolled my own. Not that hard. [import]uid: 160496 topic_id: 29498 reply_id: 118400[/import]

Not sure what you mean. Rolled? Is that WOW for created your own or you rolled the picker and it stopped in the right place? [import]uid: 103163 topic_id: 29498 reply_id: 118401[/import]

:slight_smile: “rolled my own” expression’s origin is way before WoW.

Anyway - I needed a pick wheel that was much more economical in terms of space it took and more flexible than Corona or iOS’s one. So I wrote my own. Had to fiddle with the flicking speed and soft landings etc, but it works pretty well, and it is under my full control.

It is specific to my stuff (number entry - with min, max and inc - so can do all numbers from 0 to 10, with 0.1 increments, for example), no mult columns etc. It is also not releasable as is, I would have to document and prettify it for release. But it wasn’t extremely hard to write.

[import]uid: 160496 topic_id: 29498 reply_id: 118402[/import]

Thats fine to do that and may be a good option for you, and was this free or open source then great, but time is money and I begrudge writing my own widget when I pay $349 to have the framework there for me, and if I have to start writing my own I will choose open source.

However, my frustrations aren’t directed at yourself and thx for the info

[import]uid: 103163 topic_id: 29498 reply_id: 118403[/import]

@Leginus, can you send me a little sample which exhibits this behavior?

I just tested and tested and cannot get it to get stuck between two values with the test case I have at my end. (With build 868)

Also the way it was implemented should make this scenario impossible.

I would greatly appreciate you sending me something with instructions on how I can make it fail, my address is: danny[at]coronalabs[dot]com [import]uid: 84637 topic_id: 29498 reply_id: 118404[/import]

Hi Danny

I ran the widget demo from the latest daily build. I haven’t used my own code as its from 644
If you flick the picker wheel it can easily land between two numbers.

If for any reason you can’t replicate I can send you a video tomorrow of the behaviour.

Thanks
Leginus
[import]uid: 103163 topic_id: 29498 reply_id: 118405[/import]

@Leginus, thanks I will try that right now.

Edit:

You have found a bug with the pickerwheel here.

The problem is that the “top” parameter of the pickerWheel is used in the calculation to decide which row the picker wheel should softland to.

When it’s position isn’t set to it’s final resting position as default (ie in the picker demo it transitions to y = 258) then it’s position isn’t being updated and its calculations end up wrong.

This is a mistake on my part and I apologize. The good news is that you do not have to wait for a fix (obviously there will be one asap)

If you open the widget demo’s main.lua file. Change the pickers declaration on line 299 to this:

-- create pickerWheel widget local picker = widget.newPickerWheel{ top=258, --Set to whatever position the picker will be at when it is on screen fully font=native.systemFontBold, columns=columnData, } picker.y = 480 --Set it's initial y position here instead of top until bug is fixed. [import]uid: 84637 topic_id: 29498 reply_id: 118406[/import]

Thanks Danny. That’s was fast :).
That’s good news to hear on the fix. I shall try it tomorrow as its a bit late here and been a loooong day

Thanks
Leginus
[import]uid: 103163 topic_id: 29498 reply_id: 118408[/import]

@Leginus: The bug has now being fixed and the fix should be available in one of the upcoming daily builds.

Thank you for pointing this out, and If you must blame anyone blame me. I was the person responsible for implementing the pickerWheels soft-landing feature, no one else.

Thanks again. [import]uid: 84637 topic_id: 29498 reply_id: 118414[/import]

HI Danny

Perfect! Works a treat! Thanks for your extremely quick response, that is very much appreciated and I don’t blame anyone, was just concerned about this issue having to go through the mill again.

However, faith restored, great service, fix and response time.

Thanks again
Leginus [import]uid: 103163 topic_id: 29498 reply_id: 118441[/import]