Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    TabsReorderedEvent missing vital info?

    Hi, I want to update my data model when reordering tabs in a TabSet. I enable reordering and add a "TabsReorderedHandler" handler in which I get a callback with a "TabsReorderedEvent". In this event I would expect to find which tab that was moved, and the new index, but I cannot find such info.

    Is there anything I have missed, or is this info not available? In the latter case, I would like to add it to the feature wishlist :)

    I would expect something like:

    event.getTab() and
    event.getNewIndex()

    I use SmartClient Version: v11.0p_2016-11-04/LGPL.
    Last edited by bjulleseter; 24 Nov 2016, 03:43.

    #2
    We've added getTab() and getTabIndex() methods to the TabsReorderedEvent - you can test them out in builds of 6.0+ dated December 1 and later.

    Comment


      #3
      Thanks! Very much appreciated! :)

      Verified in SNAPSHOT_v11.1d_2016-12-08/LGPL Development Only (built 2016-12-08)

      EDIT:
      Just a small comment. When I get the tab with event.getTab() - the returned Tab object seems to be a copy of the original Tab object in the TabSet. This assertion fails:

      Code:
      tabset.addTabsReorderedHandler(new TabsReorderedHandler() {
        @Override
          public void onTabsReordered(TabsReorderedEvent event) {
            Tab tab = tabset.getTab(event.getTabIndex());
            Tab tab2 = event.getTab();
      
      [B]      assert (tab.equals(tab2));[/B]
      Not a big deal, but we often iterate over the TabSet to find a specific Tab object - so the Tab from event.getTab() was not usable for us.
      Last edited by bjulleseter; 8 Dec 2016, 05:45.

      Comment


        #4
        Hi bjulleseter,

        how about comparing via myTab.getID()?

        Best regards
        Blama

        Comment


          #5
          @Blama: Yes, thanks for your comment. We could have used getID/setID instead. The most important thing was to find the tab or the new index of the tab being moved. This works fine now.

          Comment


            #6
            Actually - the event.getTab() method returns a tab that does not exist in the TabSet. Even if I assign IDs to all the tabs in the TabSet when they are created - this assert fails:

            Code:
            tabset.addTabsReorderedHandler(new TabsReorderedHandler() {
              @Override
                public void onTabsReordered(TabsReorderedEvent event) {
                  Tab tab = event.getTab();
                  assert(!Str.isNullOrEmpty(tab.getID()));
            Is there any reason for this behaviour? I would appreciate if the tab returned in the event was the same object with the same ID and object reference as the one originally reordered.

            Comment


              #7
              We see this behavior and we'll take a look - in the meantime, call setName() on your tabs (as well as or instead of setID()) - you can then get at the tab proper in your event handler with TabSet.getTab(event.getTab().getName()).

              Comment


                #8
                I can work around it, but we appreciate if this is being fixed. Thanks for the quick response!

                Comment


                  #9
                  In fact, you're getting the right object in your handler, but Tab isn't a real widget class and it's handling of global IDs is internal - getID() doesn't just return this.ID, but a mapped value - we'll look into it and update here when it's fixed.

                  For now, just use getAttributeAsString("ID") instead of getID().
                  Last edited by Isomorphic; 19 Dec 2016, 02:46.

                  Comment


                    #10
                    Ok. Thanks. What puzzles me is the assert that failed inside the event:

                    Code:
                    Tab tab = tabset.getTab(event.getTabIndex());
                    Tab tab2 = event.getTab();
                    
                    assert (tab.equals(tab2));
                    ... which indicates that the two objects are different. I still do not understand why this assertion fails. Shouldn't those Tabs be the same object?

                    Comment


                      #11
                      Actually - after digging deeper - this is very disturbing. We had another bug in our application where we have one ButtonClickHandler in which we try to figure out which button that was clicked in a dialog box by comparing the event.GetButton() with the buttons we added to the dialogbox - and the comparison now fails for two objects that clearly is the same object. It is the same symptom as in the TabsReorderedEvent - where event.GetTab() does not equals any of the tabs from the TabSet. Here is a minimal reproduction sample where the assertion fails:

                      Code:
                      import com.google.gwt.core.client.EntryPoint;
                      import com.smartgwt.client.widgets.Button;
                      import com.smartgwt.client.widgets.Dialog;
                      import com.smartgwt.client.widgets.events.ButtonClickEvent;
                      import com.smartgwt.client.widgets.events.ButtonClickHandler;
                      
                      public class MainWindow implements EntryPoint {
                      
                          @Override
                          public void onModuleLoad() {
                              
                              Dialog dialog = new Dialog();
                              Button button = new Button("Button");
                              
                              dialog.setButtons(button);
                            
                              dialog.addButtonClickHandler(new ButtonClickHandler() {
                                  @Override
                                  public void onButtonClick(ButtonClickEvent event) {
                                     [B] assert event.getButton().equals(button);[/B]
                                  }
                              });
                              
                              dialog.draw();
                          }
                      }

                      Comment


                        #12
                        There was indeed a problem with the TabsReorderedEvent, which we've corrected in SGWT 6.0p and newer branches. The fix will be in the nightly builds dated 2016-12-22 and beyond. That event actually contains the live Canvas associated with the tab, not the tab config properties object, so we've changed the associated API from getTab() to getTabCanvas(). The revised version of your sample code would look like:

                        Code:
                        Canvas tab = tabSet.getTabCanvas(event.getTabIndex());
                        Canvas tab2 = event.getTabCanvas();
                        assert (tab.equals(tab2));
                        As far as the last post, with the Dialog, what you describe is intended behavior. The SGWT Buttons provided through the setButtons() API are used as templates to create live buttons, unless those SGWT Buttons have already been created (isCreated()) and so already have SC JS Button instances associated with them. In your case, the SGWT Button hasn't been created, so it will be used as a template to create a SC JS Button instance that will ultimately create its own live SGWT Button wrapper, different from the template.

                        We will be updating the javadocs for Dialog.setButtons() to clarify this behavior.

                        If you really want your button above to be used as the live object, you can create the SC JS instance manually, by calling button.getOrCreateJsObj() before dialog.setButtons(button).

                        Comment


                          #13
                          We've added a new API, BaseWidget.completeCreation(), which will force an SGWT widget to be instantiated so that you don't have to understand the lifecycle of the underlying SmartClient JS objects. In your sample code above, that API can be called on any widgets that you want to be live objects before you pass them to Dialog.setButtons().

                          Comment


                            #14
                            Thanks for the explanations and for following up on this! We really appreciate it!

                            Comment

                            Working...
                            X