<Swing Dev> Possible bug - buttons do not regain rollover state after reenabling

[Alexander Potochkin]

Hello Martin

Your observation is correct,
Swing doesn't count a button as rollovered
if it was disabled and enabled again
(actually I haven't seen a GUI library
which is ready for such situations)

This problem very rare affects anybody
so I'd see it as a Swing limitation
(however limitation is a bit too strong word for this case)

While it is definitely possible to fix this bug
I doubt it worth doing, because in this case
we'll have to fix tons of other cases when a component
was moved/disabled/hidden and shown again
which is not reasonable

Here is a workaround for your test case:

     private void disableButtonTemporarily() {
         button.setEnabled(false);
         Timer timer = new Timer(1000, new ActionListener() {
             public void actionPerformed(ActionEvent e) {
                 button.setEnabled(true);
                 Point l = MouseInfo.getPointerInfo().getLocation();
                 Point buttonLocationToScreen = new Point();
 
SwingUtilities.convertPointToScreen(buttonLocationToScreen, button);
                 if (new Rectangle(buttonLocationToScreen, 
button.getSize()).contains(l)) {
                     button.getModel().setRollover(true);
                 }
             }
         });
         timer.setRepeats(false);
         timer.start();
     }


Thanks
alexp


> Hi,
> 
> Sorry to intrude without a proper introduction. I just want some insight 
> before reporting a possible bug.
> 
> A friend of mine asked me to help him with a problem he has with a swing 
> app. In this app some buttons are disabled for a short period of time, 
> after which, if the user has not moved the mouse, the button doesn't 
> show the rollover state after becoming enabled again. I tested this on 
> Java6 update 3, using this quick&dirty test:
> 
> ------------
> 
> import java.awt.event.*;
> import javax.swing.*;
> 
> public class RolloverTest extends JFrame {
>     private JButton button;
> 
>     public static void main(final String[] args) {
>         SwingUtilities.invokeLater(new Runnable() {
>             public void run() {
>                 new RolloverTest();
>             }
>         });
>     }
> 
>     public RolloverTest() {
>         super("Rollover Test");
>         createButton();
>         setDefaultCloseOperation(EXIT_ON_CLOSE);
>         pack();
>         setVisible(true);
>     }
> 
>     private void createButton() {
>         button = new JButton("Press me");
>         button.addActionListener(new ActionListener() {
>             public void actionPerformed(ActionEvent e) {
>                 disableButtonTemporarily();
>             }
>         });
>         add(button);
>     }
> 
>     private void disableButtonTemporarily() {
>         button.setEnabled(false);
>         Timer timer = new Timer(1000, new ActionListener() {
>             public void actionPerformed(ActionEvent e) {
>                 button.setEnabled(true);
>             }
>         });
>         timer.setRepeats(false);
>         timer.start();
>     }
> }
> 
> -----------
> 
> Sorry I couldn't test it on the latest codebase, I don't have an 
> environment set up for that purpose. Please check if you can that this 
> also happens with later versions of Swing or the JDK.
> 
> Also, I did some digging in the source at openjdk to see what could be 
> the problem. Since it happens not only with JButton, but also to 
> JMenuItem, JCheckBox, etc, at first I thought that the problem might be 
> in the DefaultButtonModel, that the flag was simply lost when the button 
> is disabled. But apparently DefaultButtonModel.setEnabled() unsets other 
> flags but not the rollover state, although 
> DefaultButtonModel.setRollover() prevents changes to the rollover flag 
> if the button is disabled. In consequence, I couldn't manage a 
> workaround by providing a different ButtonModel.
> 
> It seems that AbstractButton.setEnabled() forces the rollover state to 
> change before disabling the button. There's no comment on the source as 
> to why this state change is handled by AbstractButton and not by the 
> ButtonModel, as happens with the other states. Is there a reason why 
> AbstractButton.setEnabled() has to handle the rollover and not 
> ButtonModel.setEnabled()? It seems that this is due to the order of how 
> event propagation is to occur, but I'm uncertain.
> 
> ----------
> 
> setEnabled in AbstractButton:
> 
>     public void setEnabled(boolean b) {
>         if (!b && model.isRollover()) {
>             model.setRollover(false);
>         }
>         super.setEnabled(b);
>         model.setEnabled(b);
>     }
> 
> setEnabled in DefaultButtonModel:
> 
>     public void setEnabled(boolean b) {
>         if(isEnabled() == b) {
>             return;
>         }
> 
>         if (b) {
>             stateMask |= ENABLED;
>         } else {
>             stateMask &= ~ENABLED;
>             // unarm and unpress, just in case
>             stateMask &= ~ARMED;
>             stateMask &= ~PRESSED;
>         }
> 
> 
>         fireStateChanged();
>     }
> 
> ----------
> 
> If AbstractButton didn't force the rollover to false, and let the 
> ModelButton handle this, an implementation of ModelButton could store 
> the right state of the rollover even though it would be superseded by 
> the enabled state ( i.e. although rollover is true, it would be shown as 
> false if enabled is false). Therefore, when the button is reenabled, the 
> rollover could be restored as expected. But that's only if there isn't a 
> special reason why AbstractButton has to handle the rollover state 
> before disabling the button.
> 
> That's all. Sorry for the long mail.
> 
> Best Regards,
> 
> Martin Alterisio