Posted on by

NOTE: This tutorial is outdated. Please refer to the documentation for details and usage examples.


Posted by . Thanks for reading...

41 Responses to “Tutorial: New Widgets, Part 3”

  1. Mitaten

    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

    Reply
  2. Hector

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

    Regards
    Hector

    Reply
    • Brent Sorrentino

      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.

      Reply
    • danny

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

      Reply
  3. Francisco

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

    Reply
    • Brent Sorrentino

      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.

      Reply
  4. Chevol

    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.

    Reply
    • Brent Sorrentino

      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.

      Reply
    • danny

      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.

      Thanks

      Reply
  5. Sam Tannen

    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.

    Reply
  6. Craig

    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

    Reply
  7. Jack01

    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.

    Reply
    • danny

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

      Reply
  8. Olivier

    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″
    Thanks
    Olivier

    Reply
  9. Jyrki

    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?

    Reply
  10. DeadpanDodo

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

    Reply
  11. lessmsios

    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.

    Reply
    • Brent Sorrentino

      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?

      Reply
  12. Alberto

    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.

    Reply
    • Ross

      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.

      Reply
  13. Peter

    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…

    Reply
  14. Brent Sorrentino

    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.

    Brent

    Reply
  15. frank

    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 ?

    Thanks
    Frank

    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 )
    end

    Reply
  16. Simon Fearby

    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

    Reply
    • Brent Sorrentino

      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

      Reply
      • Stephan

        Hi Brent,

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

        Kind regards,
        Stephan

        Reply
        • Brent Sorrentino

          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.

          Brent

          Reply
          • Stephan

            Hi Brent,

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

            Kind regards,
            Stephan

  17. Dewey

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

    TableView:

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

    Thanks–D

    Reply
    • Brent Sorrentino

      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).
      http://www.coronalabs.com/blog/2013/07/16/tutorial-stylizing-widgets-part-1/

      Brent

      Reply

Leave a Reply

  • (Will Not Be Published)