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

  1. 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

  2. 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.

    • 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.

  3. “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 :-(

  4. 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.

    • 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.


  5. 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.

  6. 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

  7. 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.

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

  8. Hi,
    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”

  9. Hey,

    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?

  10. 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.

    • 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?

  11. 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.

    • 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.

  12. 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…

  13. 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.


  14. Brent,

    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 =

    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 )

    • 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).


        • 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.


  15. 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).


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>