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

@searchm: received. Thanks!!!

alex

You’re welcome. Can’t wait to use rock solid widgets soon.

I also mentioned in the bug report that the isLocked feature doesn’t work.

regarding the scrollView widget:

beside the sloppy scroll behaviour in scrollView there’s also another tiny bug, which maybe also affects the tableView ( I’m not sure ):

Video:

Scroll to the bottom a little slower and the scrollbar will sometimes go beyond the limit. If the scrollView height is smaller then the display height it will not respect the limits. It will jump to where it belongs when the scrolling is done though.

https://vimeo.com/89618405

and please implement a onClose, onChange Listener :slight_smile:

Huge batch of widget fixes in today’s daily build (2014.2282). Thanks Alex!!!

List of fixes copied below. Please take the time to update your items fixed in the spreadsheet so I can move them to the Fixed tab. Also please post your remaining issues / bugs on this thread & spreadsheet for visibility. Thanks!!!

  • #30999 - Picker acting up when in a group that has been moved after picker added
  • #31659 - PickerWheel ( widgets 2.0 ) snapping errors
  • #26258 - Widget PickerWheel not working properly
  • #25621 - Runtime error calling ‘widget.newPickerWheel’
  • #25381 - PickerWheel does not behave properly when display.CenterReferencePoint used
  • #24715 - PickerWheel soft landing fails to select correct target
  • #31422 - TableView 2.0 bugs
  • #31490 - ScrollView - combination of setIsLocked and setScrollHeight hides scrollbar
  • #31096 - ScrollView incorrect Scrolling effect after ‘setScrollHeight’
  • #30976 - ScrollView does not move smoothly, sometimes with jerkiness & choppiness
  • #31363: takeFocus does not work with multiple ScrollViews
  • #31460: Widget PickerWheel values greyed out
  • #31694: PickerWheel on Android does not highlight chosen row
  • #29657: Inserting rows into a newTableView makes the TableView scrollable
  • #26164: TableView and ScrollView Widgets scroll-back bug
  • #30679: Incorrect Error Message for widget.newSlider (spelling error)
  • #28956: newSegmentedControl does not work if anchorX is <> .5
  • #31219: TableView: Categories do not re-render properly
  • #29658: Scrolling behaves differently depending on touch location( widget.newTableView )
  • #29560: scrollToIndex() does not obey the bottom of the list when jumping
  • #26388: widget.newScrollView() has a sharp autosnap regardless of touch event
  • #29266: ScrollView problem with :setScrollHeight( newHeight )
  • #28959: TableView listener does not send “moved” phase
  • #26478: scrollToPosition in Widgets 2.0

Can confirm the following

  • #31460: Widget PickerWheel values greyed out

But there is a new MAJOR bug… I have a pickerWheel with 3 entries (single column, 3 rows) and alignment goes haywire. I add more rows to the same pickerwheel and it gets normal once you have about 10. Before 2282 3 entries were working just fine. Hope this can be corrected soon as I want to be able to enjoy all the other fixes in 2282. 

Edit : Reported bug - Case 32337) PickerWheel with few entries has major alignment problem - Regression bug in 2282

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.

Hi Guys,

Back here after a few months away and now back getting ready to publish. But have found my app, which works like lightning{fast and slick}  and friends have suggested I get it in the app store needs to be built on Graphics 2.0 … Oh dear!

I have just been using the Starter system back level to build and test. I would like some advise of moving from back-level to the latest public release or to a daily build licence BASIC. 

My experience of going to Graphics 2 on the latest public built is, well, totally un-usable and certainly not publishable due to really reeeeeally slow tableview response {2-10 secs, some time 15 secs now, when it took millisecs on back level} . Also compatibilty mode=1 does not fully work, and tableview scrolling is clunky.problem could be masses of warning messages about reference points (can these be turned off?}

I have made a forum entry at

http://forums.coronalabs.com/topic/47435-can-i-publish-to-app-store-on-back-level-corona-sdk-etc/?p=246484

Thanks for any comments/suggestions.

I cannot publish now as these problems look like a lot of work to even get close to what was a great and usable app…

Corona widgets are not the most stable critters; I’ve posted about this before.

That said, I’m using TableViews with the latest daily build with ~200 items and have had good performance on actual devices. Once you get to ~1000+ items there’s a noticeable lag time (perhaps 500ms-1000ms) when building the TableView, so I would avoid that if possible. This is using Graphics 2.0 *not* in compatibility mode.

I suggest you try converting a few screens of your app to native Graphics 2.0 and see if that solves the performance problem. It’s not as painful as you might think.

I have found the cause of my performance problem-far far too many warnings. These did not occur in earlier builds-there was a bug in my code referencing a nil object in setreference. Corrected and messages gone, so very fast again now.

My table lists are very small -max 52 entries, but many many different scenes/views [over 60 combinations can be chosen].

I also overcome the tableview problem when deleteall is done and new entries added the tableview then starts centre screen.

Due to my short lists it is just as fast to re-buld from new and everything displays correctly.

So I am hanging in on to compatibility mode at the moement.

My final funny is on one tableview it will not show all 12 entries, only the first 10 that fill the window. Thereon you cannot scroll up.

If I model a iPhone 5 all 12 entries can be seen because it is taller… so the code is working.

So this tableview now is a problem. it is acting as if it is locked. If I code a scrollto 12 it works by showing entry 12 until you scroll back manually, then it stays locked showing the first ten entries.

Thanks for the advice. Once I clear these I am almost ready to publish again-I hope…

Withdraw my last comment-I can’t publish yet as I have found categories are moving to far right and cannot fully scroll to last entries in tableviews. Can scroll but last few rows are hidden…

Known problems I suspect… recoding to direct interface without compatibility to see if there is a difference.

Seconded. It will register the center of the scrollView’s contents at the top edge of the scrollView.

Huge batch of widget fixes in today’s daily build (2014.2282). Thanks Alex!!!

List of fixes copied below. Please take the time to update your items fixed in the spreadsheet so I can move them to the Fixed tab. Also please post your remaining issues / bugs on this thread & spreadsheet for visibility. Thanks!!!

  • #30999 - Picker acting up when in a group that has been moved after picker added
  • #31659 - PickerWheel ( widgets 2.0 ) snapping errors
  • #26258 - Widget PickerWheel not working properly
  • #25621 - Runtime error calling ‘widget.newPickerWheel’
  • #25381 - PickerWheel does not behave properly when display.CenterReferencePoint used
  • #24715 - PickerWheel soft landing fails to select correct target
  • #31422 - TableView 2.0 bugs
  • #31490 - ScrollView - combination of setIsLocked and setScrollHeight hides scrollbar
  • #31096 - ScrollView incorrect Scrolling effect after ‘setScrollHeight’
  • #30976 - ScrollView does not move smoothly, sometimes with jerkiness & choppiness
  • #31363: takeFocus does not work with multiple ScrollViews
  • #31460: Widget PickerWheel values greyed out
  • #31694: PickerWheel on Android does not highlight chosen row
  • #29657: Inserting rows into a newTableView makes the TableView scrollable
  • #26164: TableView and ScrollView Widgets scroll-back bug
  • #30679: Incorrect Error Message for widget.newSlider (spelling error)
  • #28956: newSegmentedControl does not work if anchorX is <> .5
  • #31219: TableView: Categories do not re-render properly
  • #29658: Scrolling behaves differently depending on touch location( widget.newTableView )
  • #29560: scrollToIndex() does not obey the bottom of the list when jumping
  • #26388: widget.newScrollView() has a sharp autosnap regardless of touch event
  • #29266: ScrollView problem with :setScrollHeight( newHeight )
  • #28959: TableView listener does not send “moved” phase
  • #26478: scrollToPosition in Widgets 2.0

Can confirm the following

  • #31460: Widget PickerWheel values greyed out

But there is a new MAJOR bug… I have a pickerWheel with 3 entries (single column, 3 rows) and alignment goes haywire. I add more rows to the same pickerwheel and it gets normal once you have about 10. Before 2282 3 entries were working just fine. Hope this can be corrected soon as I want to be able to enjoy all the other fixes in 2282. 

Edit : Reported bug - Case 32337) PickerWheel with few entries has major alignment problem - Regression bug in 2282