henterji's blog

Not all menu items are boring. Some have a check mark to indicatethat the menu item has been selected...

...while others have a small black dot that performs the same function as the check mark:

The check mark is provided by the JCheckBoxMenuItem class, while the dot is there thanks to the JRadioButtonMenuItem class.

To add JCheckBoxMenuItems and JRadioButtonMenuItems to NetBeansmodules or to applications based on the NetBeans Platform, implementthe CallableSystemAction class (via the New Action wizard) and then override the getMenuPresenter()method. The cool thing is not so much the visual feedback via the checkmark or dot, but the fact that you can make things happen depending onthe state of the menu item (i.e., either selected or unselected).

 

For example, heres my class that extends CallableSystemAction, implemented for JCheckBoxMenuItem, but with comments explaining how to change the imlementation to make it work for JRadioButtonMenuItem:

public class MyAction extends CallableSystemAction {
    
    private static JCheckBoxMenuItem abc;
    //private static JRadioButtonMenuItem abc;
    private static final String ICON_PATH = "org/netbeans/mdoules/checkboxitemsample/HOMER16.png";
    private ImageIcon ICON = new ImageIcon(Utilities.loadImage(MyAction.ICON_PATH, true));
    
    public JMenuItem getMenuPresenter() {
        
        //Use the following line for JCheckBoxMenuItem:
        abc = new JCheckBoxMenuItem("Open Homer Window", null);
        
        //Use the following line for JRadioButtonMenuItem:
        //abc = new JRadioButtonMenuItem("Open Homer Window", null);
        
        //Use the following line for JCheckBoxMenuItem:
        abc.setState(true);
        
        //Use the following line for JRadioButtonMenuItem:
        //abc.setSelected(true);
        
        abc.setIcon(ICON);

        //Here we listen and then act:
        abc.addActionListener(new ActionListener() {
            public void actionPerformed(ActionEvent e) {
                TopComponent tc = MyTopComponent.findInstance().getDefault();
                if(abc.isSelected()) {
                    if (!tc.isOpened()) {
                        tc.open();
                    }
                } else {
                    if (tc.isOpened()) {
                        tc.close();
                    }
                    tc.requestActive();
                }
            }
        });
        return abc;
    }
    
    //Required by CallableSystemAction:
    public void performAction() {
    }
    
    //Required by CallableSystemAction:
    public String getName() {
        return null;
    }
    
    //Required by CallableSystemAction:
    public HelpCtx getHelpCtx() {
        return null;
    }
    
}

And thats it. The important thing to note is that all of the CallableSystemAction methods are meaningless to us; everything has to be defined within the getMenuPresenter()method that overrides the default way that a menu item is implementedin NetBeans IDE (i.e., as a boring menu item). Now, when the menu itemis selected, the window (which extends the TopComponentclass, which can also be generated from a wizard in NetBeans IDE) opensand when it is unselected, the window closes. Could come in prettyhandy sometimes.

 

Instead of overriding getMenuPresenter(), you could also override getPopupPresenter() or getToolbarPresenter(). If youre interested in the latter, see the NetBeans Google Toolbar Module Tutorial.

In the comments at the end of yesterdays blog entry, Sandipreferred to the Radio Buttons section in the Java Look and Feel Design Guidelines (which I didnt know about but am finding very useful). Sandips point was that "the JRadioButtonMenuItem or JRadioButtonare meant to be used in cases where it represents an exclusive choicewithin a set of related choices", while my example yesterday didntrepresent this kind of choice (there was only one choice, which isntreally a choice). "So," I thought, "How would I go about implementingan exclusive choice (to justify not using Sandips approach)?" Thething to use is a ButtonGroup,which is simple to implement in Matisse—just drag and drop one ontoyour form. But what about when were not designing graphically, butdoing everything in the code? And, secondly, wed need two or more menuitems, all subclassing CallableSystemAction. How are the JRadioButtonMenuItems in these separate classes going to share the same ButtonGroup? So, I now have this simple helper class:

public class ButtonGroupHelper {
    
    public static ButtonGroup bg = new ButtonGroup();
    
    /** Creates a new instance of ButtonGroupHelper */
    public ButtonGroupHelper() {
    }
    
    /** Returns a ButtonGroup */
    public static ButtonGroup returnGroup() {
        return bg;
    }
    
}

And, within the first of the two classes that subclass CallableSystemAction, I have this bit of code...

comedyChoice = new JRadioButtonMenuItem("Comedy", null);
ButtonGroup local = ButtonGroupHelper.returnGroup();
local.add(comedyChoice);

...while the second (and any subsequent classes) have the same:

romanceChoice = new JRadioButtonMenuItem("Romance", null);
ButtonGroup local = ButtonGroupHelper.returnGroup();
local.add(romanceChoice);

This lets me retrieve the same button group for each JRadioButtonMenuItem.And, this lets me implement "an exclusive choice within a set ofrelated choices". When I select "Comedy" below, "Romance" isautomatically unselected, and vice versa:

Ive set it up so that when a choice is made, a related windowis opened and, if the other window is open at the same time, it isclosed. This means either the "Comedy" or the "Romance" window is open,but never both at the same time.