List of open Widget 2.0 bugs & promised features...

Bug #31460 appears to be resolved. 

Yes it is. My post above confirms that fact and then proceeds to reporting a new one. Case 32337

Thanks, Ksan, for flagging the widget fixes in the new daily build (I don’t always pay attention to each one).

And, Rob, thanks for helping us get these fixes made.

Can I nudge you into giving us a status update on two scrollView issues that it looks like are still unresolved? The first is restoring the deleted “ended scroll” event:

http://forums.coronalabs.com/topic/43778-restoring-deleted-scrollview-feature-endedscroll-event/?hl=corona273#entry229193

The second is being able to set a maxVelocity parameter for a scrollView in much the same way you can a tableView. Note this is *not* the same as friction, which both widgets do have: friction is how long it continues to scroll, not how fast you can scroll during that time.

I recall one of your colleagues told me in email a month ago that both would be resolved in the not-so-distant future, but I haven’t heard anything since (nor have I tried to bug him for an update).

This is better than christmas :slight_smile:

Thanks Alex!

@sunmills: you’re welcome.

@ksan: 32337 is in the works.

@corona273: on it.

Thanks,

alex

Great! Thank you very much for your quick response and continued efforts here. The batch is amazing. 

Not a big widget 2.0 user, still using 1.0 as 2.0 still feels a bit unreliable, but with the most recent daily it looks to have made some GREAT progress. Thank you Alex for that! :slight_smile:

Would just like to add, as I’m not sure if anyone else has reported this before but if you “tap” on a tableView row, ie the event.phase is “tap”, the onRowTouch listener doesn’t get the entire event table that the “press” and “release” phases come with. It for example misses the event.target.row table and what nots. Not a big deal as these tables can be accessed in other ways as well, but just wanted to throw this in here.

Thanks again! :slight_smile:

No fix for 31640 – 1.0 compatibility mode causes tableView to position itself incorrectly on swipe up (and also in some other cases).

Also described here:

http://forums.coronalabs.com/topic/45794-tableview-positions-itself-wrong-in-10-compatibility-mode/?p=239370 

32337 is worse, but 31640 is too serious to roll out with it.

Alex can you kindly post the list of recent updates that went live in 2332 and 2338? Thank you so much for your hard work and continued efforts. 

Yep, if anyone from Corona could address this, I’d be much obliged as well. What does “Update widget to latest” mean. for instance?

Hey guys,

2332 and 2338 contain:

31768 - widget.newSegmentedControl() – segments not highlighting properly
31769 - widget.newSegmentedControl() – divider frame broken and dysfunctional
31772 - widget.newSlider() – handle width/height not respected.
31773 - widget.newSlider() – fill parameters missing or not respected.
31914 - widget.newPickerWheel() – column items mis-aligned if optional “align”  property is not specified.
31761 - widget.newPickerWheel() – custom skinning frame offset issue
31762 - widget.newPickerWheel() – labels colors not highlighting properly.
31763 - widget.newPickerWheel() – can’t select the final option in any column.
31764 - widget.newPickerWheel() – fontColor is non-functional
31770 - widget.newSegmentedControl() – labelColor 'over’ dysfunctional
30390 - SetFillColor not working on widget button
29143  - obj:setValue() method is not yet implemented for newSegmentedControl() (I added object:setActiveSegment(segmentNum) for this)
32337 - PickerWheel with few entries has major alignment problem - Regression bug in  2282

Thanks,

alex

Alex, this is a great list! Thanks much for your continued hard work. 

Question, given all the fixes we see listed above for the segmentedControl are we now at a point where we can skin this thing? Will there be an update to the API pages showing us how to change the visuals of a segmentedControl soon? 

Looking forward to more of your good work and Brent’s updates on the API pages. Thank you very much!!!

Sure thing. One mention though, Brent and Rob had a huge contribution to the last two widget fixes batches. So with your permission, Kerem, i’ll redirect your thanks to them as well.

Thanks,

alex

Absolutely, I didn’t know or otherwise I would be the first to say thanks. So lets correct that now! 

Rob, Brent, thank you very much for your continued support and help in getting these widget fixes out. Most appreciated.

You’re welcome all. The (daily) docs are now fully updated with skinning details for all widgets, and visual examples of how it should be done:

http://docs.coronalabs.com/daily/api/library/widget/index.html

I know this took much longer than expected and I appreciate your patience. As usual, if you find any glaring issues, please isolate test cases and file them as bugs so that we may investigate and fix them.

Thanks,

Brent

P.S. - I noticed one broken link in newSegmentedControl() for the “:setActiveSegment()” method. This is just formatting issue which I’ll fix right away… the method should still work fine (just provide a valid segment number as the sole argument to the method).

Best news ever!!! So it is true? I can skin a segmentedControl now? I will try this right away!!! Thank you very much guys. This made my day. 

Yup, the :setActiveSegment() method works great! Already tested and its used in a released app. Great going.!

Im sorry to disturb the Celebration.

I was so happy to hear that the PickerWheel finally should work.

Download latest NightBuild: 2340

and tested the Pickerwheel.

Does nobody else see that after u created a simple pickerwheel,

(for example: just with one column and lets say 50 Rows of numbers 1-50)

and u scroll up/down fast… it seems it will stop soon… than it makes a big jump und goes 4 Rows further to stop.

When u scroll up its even worse, u cant exactly stop above a number. It will also jump suddently 3 Rows further to stop.

Result:  PICKERWHEEL still buggy and not fixed :frowning: Unusable…

in the Simulator when u scroll to the first Row… and than strongly move down… the numbers jump from centered to left aligned in a mix.

Better luck, next time.

Greets

Chris

For me it is past a point where I can live with the remaining issues while hopefully they get tackled one by one soon as well. I know it will never be perfect or match 100% the native UI elements but they are good enough & close enough for what I need them to do for me. I know there is ways to go but IMHO, the light at the end of the tunnel is getting stronger by the day. 

just to give an example.

its not about to be a 100% native ui for me… instead just a working one :slight_smile:

here a video… hope that makes it more clear and is helpful to track the bug

We were glad to help.