newPickerWheel labels mis-aligned not fixed?

[RealHandy]

The recent daily build 2481 lists bug 33559 as fixed:

Widgets - newPickerWheel() labels mis-aligning - casenum 33559

Which is a bug that’s been bothering our current release since the last round of widget fixes. But it’s not fixed in my windows simulator (see pic) on build 2496. Am I misunderstanding what 33559 was, or is this not really fixed? It might be that the only issue now is that an unspun wheel starts in a different alignment, so that all unspun wheels align and all wheels spun at lease once align, but unspun wheels don’t align with spun wheels.

In the attached pic, the year has not yet been spun, but the month and day have been . . .

Thanks,

Andy

[rob]

This likely a different issue.  The bug in 33559 was about scrolling a picker wheel quickly and scroll past the end of the wheel, when they spring back they are out of alignment.  There was also a runtime error apparently attached to this behavior.  This is what’s fixed.

I didn’t see any other alignment bugs that have been filed.  Can you file a bug report on it?  Make sure to include a test case with the problem, the config.lua and build.settings and any assets.  Put all of that in a .zip file, click on the File a bug report link at the top of the page.  You will be emailed a case # after you file.  Please post that case # back here as a reference.

Thanks

Rob

[RedBeach]

I was messing around with PickerWheel to make it support different content sizes (not only the default 320 x 480) and I saw that bug when using a different content size (don’t remember of seeing it when having a 320 x 480 content size).

On my case, I noticed that the wheel stopped on slightly different positions when it was rolling than when I simply clicked on a specific value.  That bug was actually coming from the tableview (which is used to create the pickerWheel).

@RealHandy, if you that is the same bug you are facing, you can try my widget fork that is already fixed for that (you would just need the pickerWheel and tableView) :

https://github.com/renatosc/framework-widget

[RealHandy]

@Renato,

Yep, I’ve done some things with the pickerWheel to change the default widths. I’ll definitely take a look at your fork. I’ve been sticking with the Corona build of widgets to avoid all the other problems that can crop up from forks, but I really appreciate your knowing about this problem. Do you think it’s a small fix that could be provided on its own to Corona, or is does it impact a lot of lines of code?

Thanks!

[RedBeach]

If I remember correctly the fix is 3 lines of code on the tableview widget (which is used on the pickerWheel).

The problems are:

1. I would guess that Corona would not fix it with the excuse that you changed the width of the widget and that should not be changed

2. You know Corona (just read your other post about tableview 1.0 compatibility), they will take months to fix (if they ever fix it at all)

Said, but that is the truth.

[rob]

This likely a different issue.  The bug in 33559 was about scrolling a picker wheel quickly and scroll past the end of the wheel, when they spring back they are out of alignment.  There was also a runtime error apparently attached to this behavior.  This is what’s fixed.

I didn’t see any other alignment bugs that have been filed.  Can you file a bug report on it?  Make sure to include a test case with the problem, the config.lua and build.settings and any assets.  Put all of that in a .zip file, click on the File a bug report link at the top of the page.  You will be emailed a case # after you file.  Please post that case # back here as a reference.

Thanks

Rob

[RedBeach]

I was messing around with PickerWheel to make it support different content sizes (not only the default 320 x 480) and I saw that bug when using a different content size (don’t remember of seeing it when having a 320 x 480 content size).

On my case, I noticed that the wheel stopped on slightly different positions when it was rolling than when I simply clicked on a specific value.  That bug was actually coming from the tableview (which is used to create the pickerWheel).

@RealHandy, if you that is the same bug you are facing, you can try my widget fork that is already fixed for that (you would just need the pickerWheel and tableView) :

https://github.com/renatosc/framework-widget

[RealHandy]

@Renato,

Yep, I’ve done some things with the pickerWheel to change the default widths. I’ll definitely take a look at your fork. I’ve been sticking with the Corona build of widgets to avoid all the other problems that can crop up from forks, but I really appreciate your knowing about this problem. Do you think it’s a small fix that could be provided on its own to Corona, or is does it impact a lot of lines of code?

Thanks!

[RedBeach]

If I remember correctly the fix is 3 lines of code on the tableview widget (which is used on the pickerWheel).

The problems are:

1. I would guess that Corona would not fix it with the excuse that you changed the width of the widget and that should not be changed

2. You know Corona (just read your other post about tableview 1.0 compatibility), they will take months to fix (if they ever fix it at all)

Said, but that is the truth.