Announcement

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

    Issue with CanvasItem as Cell Editor

    When editing a cell using a custom cell editor that extends CanvasItem (e.g. SliderItem, ButtonItem), the background color for the entire row changes when the mouse moves over the CanvasItem. This doesn't happen with editors that do not extend CanvasItem. Is there a way to disable this behavior?

    This can be seen in the following showcase example by editing the field value that uses the Slider Editor.

    http://www.smartclient.com/smartgwt/...m_editing_cell

    Thanks
    Last edited by stonebranch3; 23 Feb 2015, 07:45.

    #2
    Hi stonebranch3,

    for me, all rows show the same behaviour. Only difference for the row with the slider is that it gets larger when it is being edited.
    All rows get a blue background in both columns when editing (FF26).

    Best regards,
    Blama

    Comment


      #3
      Thanks for checking Blama. I'm seeing this behavior on FF and Chrome, but you have to click the value field cell without moving the mouse. Once the editor appears, you can then move the mouse and the row background color changes.

      I noticed that when using a CanvasItem cell editor, the cell style changes from tallCellSelected to tallCellSelectedOver which uses a different background color. I'm looking for a way to prevent the cell style from changing without disabling rollovers.

      Comment


        #4
        Ah, now I'm seeing it, too. The background changes from light blue to still light blue, but a bit darker.

        Comment


          #5
          Isomorphic,

          I was able to get this to work by adding editor enter/exit handlers to the ListGridField to disable the rollover while in edit mode.

          Code:
                  valueField.addEditorEnterHandler(new EditorEnterHandler() {
          
                      @Override
                      public void onEditorEnter(EditorEnterEvent event) {
                          ListGrid grid = event.getGrid();
                          if (grid != null) grid.setShowRollOver(Boolean.FALSE);
                      }
                  });
          
                  valueField.addEditorExitHandler(new EditorExitHandler() {
          
                      @Override
                      public void onEditorExit(EditorExitEvent event) {
                          ListGrid grid = event.getGrid();
                          if (grid != null) grid.setShowRollOver(Boolean.TRUE);
                      }
                  });
          This extra step is only required for CanvasItem editors since they will change the style to tallCellSelectedOver when in edit mode. This appears to be a bug since it works fine with other subclasses of FormItem such as TextItem, SelectItem, etc. That is, they do not use the "Over" style when in edit mode by default.

          I'm using SmartClient Version: v9.1p_2015-02-11/Pro Deployment (built 2015-02-11).

          Thanks.

          Comment


            #6
            Isomorphic,

            Can you confirm if this is a bug or not?

            Thanks.
            Last edited by stonebranch3; 6 Mar 2015, 06:45.

            Comment


              #7
              Indeed this is / was a bug.
              We've made a change to address it today. This fix will be in the next nightly build, dated March 6 or above, in the 5.0p and 5.1d branches

              Regards
              Isomorphic Software

              Comment


                #8
                Thanks. I will verify the fix once we upgrade.

                Comment


                  #9
                  Isomorphic,

                  This might have been fixed in an earlier build, but I'm still seeing the issue with SmartClient Version: v10.0p_2015-05-28/Pro Deployment (built 2015-05-28)

                  Thanks.

                  Comment


                    #10
                    Thanks for the notification. This is queued up for re-investigation. We'll follow up when we have more information for you. In the meantime, hopefully the workaround above continues to work for you.

                    Regards
                    Isomorphic Software

                    Comment


                      #11
                      Just a quick follow up to say - we did see a remaining case where this issue could still occur and we believe we have now taken care of it in both 5.0 and 5.1 builds.

                      This change will be present in the nightly build dated July 30 or above.

                      Regards
                      Isomorphic Software

                      Comment


                        #12
                        This is resolved in the July 30 build. Thanks!

                        Comment

                        Working...
                        X