Tutorial: New Widgets, Part 3

Share on Facebook0Share on Google+3Tweet about this on TwitterShare on LinkedIn0

NOTE: This tutorial is outdated. Please refer to the widget documentation.

Share on Facebook0Share on Google+3Tweet about this on TwitterShare on LinkedIn0

Brent Sorrentino serves as a full-time Developer Evangelist for Corona Labs, assisting developers in the forums, maintaining documentation/guides, and creating samples which highlight core features of Corona SDK.

This entry has 41 replies

  1. Carlos says:

    Thank you for this tutorial series. This is the best explanation I have seen for the Widget library.

  2. Mitaten says:

    How big is the performance difference between the new tableView and the old one? In terms of having _several_ rows inside it containing lots of display objects in each row? Is the new tableView generally better compared to the old one?

    Nevertheless great blog post

  3. Hector says:

    Thanks for these tutorials, however, I noticed a couple of potential bugs you might want to check:

    1.- “TabBar Widget”: I tested the TabBar and WidgetDemo sample codes and I noticed that the background of the tabBar from the sample code looks weird, no matter what background image I have, I can’t make it look right. I also followed the tutorial No. 2 and got the same result as the sample code.

    2.- “Scroll View Widget”: I also tested the sample code, and apparently even though the parameter “horizontalScrollingDisabled” is set to true, I can still scroll horizontally. Not sure if it has to do with the length of the “lotsOfText” variable from the sample code.

    3.- “Picker Wheel Widget”: I tested the code from both this tutorial and the one in the documentation for build 1041, and I get the following Runtime error:

    ?:0: attempt to compare nil with number
    stack traceback:
    [C]: ?
    ?: in function
    ?: in function

    I apologize in advance as it might be an error on my side for not following the tutorial correctly, but these are the errors I got while testing the new widgets


    • Brent Sorrentino says:

      Hi Hector,
      Thanks for the notes. The issues #2 and #3 that you report are known regression bugs in Build #1041, but should be resolved in #1042, to be released very soon. Issue #1 might be in the same category, but I’ll check it out. I apologize for the inconvenience.

    • danny says:

      Hey Hector.

      #2 is that there is no parameter named “horizontalScrollingDisabled” The parameter is named “horizontalScrollDisabled”

      Issues #1 & #3 are fixed and should be available in the next daily build.

  4. Francisco says:

    “This tutorial concludes discussion of the current Widgets 2.0”

    I’m still looking forward to read the tutorial about customizing the appearance of the new widgets 🙁

    • Brent Sorrentino says:

      Hi Francisco,
      I chose the wrong words there… a theme guide will be created to help developers along, but we want to focus on squashing these pesky bugs first, and ironing out the usability/features issues first. Thanks for your understanding.

      • Francisco says:

        Great to hear that! 🙂

  5. Chevol says:

    I am looking forward to the customization of the new widgets too.

  6. Chevol says:

    Brent The issues #2 and #3 are still present in build #1043! We have seen no progress on the widgets 2.0 or their bugs since Sat and the #1041 build. This has been wrecking havoc on my dev timeline. I’m now having to comment out all my newPickerWheels just so I can run code and develop again. There area too many little bugs still lingering around in these Widgets 2.0 to make them really usable. Where is the tableview row.rerender? What is the workaround/new way to do that? I appreciate all you guys hard work, I’m just worried about these new widgets becoming like the old ones and having absolutely no support with various issues/bugs.

    • Brent Sorrentino says:

      Hi Chevol,
      I looked at the build notes for #1043 and it appears the fixes did not yet roll into that build, hence the same behavior. 🙁 Let me check into this and figure out when those fixes can be expected to be made public. It should be any day now, sincerely.

      Also, the new widgets will not be allowed to wither on the vine. There will probably be some feature requests that take longer than others, especially if they apply to less common usage and “edge cases,” but in regards to a standard core base, we’re committed to making this happen. With a major revamp of an entire library like this, the growing pains and conversion issues are an unfortunate side effect. I appreciate your patience (and everybody’s patience), and also for noting these issues here and in the forums… we’re receiving all of them and taking the necessary steps as fast as we can.

    • danny says:

      Hey Chevol.

      If you look at the amount of widget 2.0 bugs that have been fixed since they were released you should be re-assured. Having “No support” isn’t the case. All bugs reported are evaluated and fixed in a priority basis.

      Some bugs just take longer to fix than others.

      We are 100% committed to resolving any issues with widgets 2.0 as fast as possible and will not stop until we reach that point.


  7. Sam Tannen says:

    Will it be possible to make a picker wheel out of rows instead of columns? This would be useful if you were populating the wheels with longer strings of text. Also, it would be great if you could use images instead of text.

  8. Craig says:

    Hey Brent. Would you be able to check into the TabBar widget object:setSelected( buttonIndex, simulatePress ) method. The simulatePress parm appears to not be working. It won’t trigger the event even when true. Thanks

  9. Jack01 says:

    I am still using Widget 1.0 for the scrollView. It does not have the need for the new fixed scrollHeight. This allows a scrollView to grow, for example when used as a chat application.

    • danny says:

      The new scrollView has support for dynamic scrollHeight sizing. It does this under the hood. That issue was fixed in daily build 1040

  10. Olivier says:

    What about the content property of scrollVIew widget, which is removed on the 2.0 version ?

    I was using this content property to move the content manually without moving the scrollView itself, which was very practical…
    How could I do that now?
    Thanks for your help

  11. Olivier says:

    I believed that scrollView:scrollTo() would do the job,
    but we only can scroll to constant position top, bottom, left, right.
    Thanks for your help

    • danny says:

      You can also use


      That should do what your are after.

      • Olivier says:

        Thank you Danny, U right…
        Sorry 🙂

  12. Olivier says:

    Is there a bug with “numChildren” property on ScrollView widget with widget 2.0 ?
    I inserted a lot of display objects on my ScrollView, and then I printed the srcollView.numChildren on terminal, it always says “2”

  13. Jyrki says:


    I downloaded daily build 2013.1050 and tried to migrate my app to use the new ScrollViewWidget. My view items have, however, touch listeners bound to them, and with widget-v1 I used to call scrollView:takeFocus(event) if event.phase was “moved”. New ScrollViewWidget does not seem to have that method, though. So how this should be done with new widget library?

  14. DeadpanDodo says:

    Same issue as Jyrki, the takeFocus is gone making the new scrollView useless.
    Going back to an old build, … as usual since 1028.

  15. lessmsios says:

    Nice tutorial – and good to see that Corona is making headway on widgets.

    In using the Table View it would really be nice if the width and height controlled the visual view as well. I’m working on an app that is size-dynamic using percentages of areas of the screen for the layout. Table View works fine except parts of the bottom rows remain out of view. I know there is the maskFile option but to have such a file for ever possible device is not practical.

    Do you see the width/height controlling both the “behavioral bounds” of the table view AND the visual boundaries in the near future?

    Thanks in advance.

    • lessmsios says:

      Ignore my post – I figured it out.

      • Bas van Beek says:

        Very clean article, thank you!

  16. frank says:

    Brent, do you have a timeline by when the widget issues are fixed ?

    • Brent Sorrentino says:

      Hi Frank,
      The widget issues are being steadily fixed and addressed as they come into the queue, and fixes rolled out in daily builds. Do you have a specific issue which I should check on the status of?

  17. Alberto says:

    Same issue as Jyrki and DeadpanDodo. How can now get that featured?
    Now my scrollview is not working 🙁
    I do everything in the Migration guide, I get no errors but the buttons in my scrollview doesn’t work.

    • Ross says:

      Alberto, Mine is not either. I must not know how to migrate from Widget 1.0 to 2.0.

      I get no scroll action with 2.0. Going to try to go to an earlier non 2.0 version.

  18. Peter says:

    Brent – Does anyone know when a tutorial for customizing widget appearances will be published? I’d love to learn how to do that with the new widget library…

  19. Brent Sorrentino says:

    Hi Peter,
    The skinning guide is already underway, but we need to make sure it covers all bases and widgets, and is very clear on the use-cases that we imagine developers will commonly need. Thanks for your patience, we know this has been requested by several users.


  20. frank says:


    regarding the tableView, isn’t your sample code of onRowRender something ? How is the group populated. In widget 1.0, we used to set the event.view. How is this done in 2.0 and where is the change documented ?


    Example from 2.0

    local group = event.view
    local row = event.target

    local text = display.newText( “My first TableView row!”, 0, 0, native.systemFont, 18 )
    text:setReferencePoint( display.CenterLeftReferencePoint )
    text.x = 25
    text.y = row.height * 0.5

    — you must insert any display objects into event.view group
    group:insert( text )

  21. Simon Fearby says:

    Is everyone else having to hold down the press a for a at leave 1000ms to get the “release” to fire in the onRowTouch( event ) widget.newTableView

    • Brent Sorrentino says:

      Hi Simon,
      The docs haven’t been updated (yet), but the row touch (in about daily build 1080 and above) now features the following events:

      tap, press, release, swipeLeft, swipeRight, cancelled

      The “tap” being what you’d expect. As for the press/release, you’ll be required to “hold down” for a very short amount of time, but certainly not 1000 ms…. maybe 250 ms or so (I can’t remember the exact value but it’s around there).


      • Stephan says:

        Hi Brent,

        is this also true for build 1135? Because we don’t get the tap event, no matter what we try…

        Kind regards,

        • Brent Sorrentino says:

          Hi Stephan,
          I’d probably need to see some code. We just tested this yesterday, and “tap” is being transmitted properly… so, there must be some other tiny issue here.


          • Stephan says:

            Hi Brent,

            thanks for your answer. It was indeed an oversight on our side. All working perfectly now.

            Kind regards,

  22. Jane Scarano says:

    Can we add a background image to the tableView? If yes, how do we do this?

  23. Dewey says:

    This tutorial is good, and could benefit from a few clarifications:


    “if you set a custom width or height” — since default W/H values are not specified, it’s not clear what constitutes “custom” — and as mentioned above, do we have to create a separate mask file for EVERY device screen size or will you guys incorporate the new dynamic mask features into the widgets??

    Also as asked above, is the control-scope of width & height planned to be changed to include visible bounds??

    Do we have an ETA on the “customizing the UI” (theming) document?


    • Brent Sorrentino says:

      Hi Dewey,
      The tableView width and height specifies only the internal values in which rows are considered “off screen” for culling purposes. This may or may not match your content area… it depends on how you design the view, and where you place it on the screen.

      Auto-masking will be resolved when we can do so, in terms of using Graphics 2.0 containers to constrain the view bounds. We just released the 2.0 beta to the public, so this is coming along, but containers have not yet been implemented into widgets.

      As for theming table view, this is discussed in this newer tutorial here. Other widgets will be discussed in future parts, hopefully coming soon (this has been delayed and I apologize for that).