Announcement

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

    Disable RibbonGroup does not call disable on the icon

    Hi,

    When disabling a whole RibbonGroup,
    the controls are set disabled (OK),
    but only the style is changed (OK),
    not the icon (NOK).

    When you disable a control itself, the icon is called to show the _disabled one (OK).

    Repro showing this difference:
    Code:
    String ICON_SKIN_ACTION_ADD = "[SKINIMG]/actions/add.png";
    
    RibbonBar bar = new RibbonBar();
    RibbonGroup group = new RibbonGroup();
    group.setNumRows(1);
    group.setTitle("Group Disabled");
    group.setRowHeight(76);
    group.setDisabled(true);
    
    IconButton button = new IconButton("Add");
    button.setIcon(ICON_SKIN_ACTION_ADD);
    button.setLargeIcon(ICON_SKIN_ACTION_ADD);
    button.setOrientation("vertical");
    group.addControl(button);
    
    IconButton button2 = new IconButton("Add");
    button2.setIcon(ICON_SKIN_ACTION_ADD);
    group.addControl(button2);
    
    RibbonGroup group2 = new RibbonGroup();
    group2.setNumRows(1);
    group2.setTitle("Buttons Disabled");
    group2.setRowHeight(76);
    
    IconButton button3 = new IconButton("Add");
    button3.setIcon(ICON_SKIN_ACTION_ADD);
    button3.setLargeIcon(ICON_SKIN_ACTION_ADD);
    button3.setOrientation("vertical");
    button3.setDisabled(true);
    group2.addControl(button3);
    
    IconButton button4 = new IconButton("Add");
    button4.setIcon(ICON_SKIN_ACTION_ADD);
    button4.setDisabled(true);
    group2.addControl(button4);
    
    bar.addMember(group);
    bar.addMember(group2);
    
    final VLayout v = new VLayout();
    v.setOverflow(Overflow.VISIBLE);
    v.addMember(bar);
    
    return v;

    build: SNAPSHOT_v8.3d_2012-07-03/Pro Deployment (built 2012-07-03)

    TIA

    #2
    Thanks for the report - we've addressed this when disabling ribbonGroup and ribbonBar in 3.1d - the fix should hit nightlies from tomorrow, 12/7

    Comment


      #3
      Thanks,
      verified and OK in SNAPSHOT_v8.3d_2012-07-17/Pro Deployment (built 2012-07-17)

      Comment


        #4
        Oops, on the fly disabling isn't fixed with the previous patch.

        Repro: click the disable button
        => icons don't show the disabled version.

        Code:
        	String ICON_SKIN_ACTION_ADD = "[SKINIMG]/actions/add.png";
        	
        	RibbonBar bar = new RibbonBar();
        	final RibbonGroup group = new RibbonGroup();
        	group.setNumRows(1);
        	group.setTitle("Group");
        	group.setRowHeight(76);
        
        	IconButton button = new IconButton("Add");
        	button.setIcon(ICON_SKIN_ACTION_ADD);
        	button.setLargeIcon(ICON_SKIN_ACTION_ADD);
        	button.setOrientation("vertical");
        	group.addControl(button);
        	
        	IconButton button2 = new IconButton("Add");
        	button2.setIcon(ICON_SKIN_ACTION_ADD);
        	group.addControl(button2);
        	
        	bar.addMember(group);
        	
        	final VLayout v = new VLayout();
        	v.setOverflow(Overflow.VISIBLE);
        	v.addMember(bar);
        	
        	Button b = new Button("DISABLE!");
        	b.addClickHandler(new ClickHandler() {
        		
        		public void onClick(ClickEvent event) {
        			
        			v.setDisabled(true);
        			
        		}
        	});
        	v.addMember(b);
        	return v;
        done with SNAPSHOT_v8.3d_2012-07-17/Pro Deployment (built 2012-07-17)



        * On a side note,
        when disabling Sections, I now see requests like this:
        Code:
        sc/skins/Enterprise/images/SectionHeader/opener_Disabled_closed.png
        so the "_Disabled" mark isn't at the end.
        Is that intended or should the code look for opener_closed_Disabled.png instead?

        Comment


          #5
          On your first point, thanks for the report - we've sorted that out and it will hit the nightlies from July 24.

          On your second point - we see the issue and will take a look.

          Comment


            #6
            When you say "when disabling Sections, I *now* see requests like this:", do you mean that this is a new behavior, or just that you hadn't noticed it before?

            If it's new, in what snapshot did you last see it working differently?

            Comment


              #7
              We're on build 19 07 2012 3.1 Pro which doesn't include the file opener_Disabled_closed.png

              At some point using a build of Feburary 1, we created opener_closed_Disabled.png ourselves but I have no proof if that solved an issue or if this filename was mistake.

              I did notice a 404 for the file opener_Disabled_closed.png, and I saw our opener_closed_Disabled.png so I assumed there was a problem in the JS code calling the wrong filename.

              We can create opener_Disabled_closed.png ourselves, so either way is fine for us. I'll remove our opener_closed_Disabled.png file. I should see 404s on that file if it was used after all.

              But anyway, it was more of a question:
              Do you in general put "_Disabled" at the end or is SectionHeader an exception to the rule?

              Comment


                #8
                Hi,

                Using v8.3d_2012-11-11/Pro Deployment (built 2012-11-11)

                The issue in the repro case from post #4 is back but the other way around:
                when hitting the disable button,
                the icon asks for its disabled version (OK),
                but now the text doesn't turn grey (NOK).

                If the group was disabled from the start, the text is grey (OK).

                Comment


                  #9
                  A quick follow up to let you know this is being worked on. We have identified the problem and should have a fix today or tomorrow. We'll follow up and let you know when it's resolved.

                  Regards
                  Isomorphic Software

                  Comment


                    #10
                    We've made a change to 3.1p and 4.0d that should have this working properly now - please retest with a build of 11/30 or later

                    Comment


                      #11
                      Thanks,
                      verified OK in v8.3p_2012-11-30/Pro Deployment (built 2012-11-30)

                      Comment

                      Working...
                      X