Skip to main content

Actions for JToggleButton and/or JCheckBoxMenuItem

3 replies [Last post]
swpalmer
Offline
Joined: 2003-06-10
Points: 0

It seems that you can't use an Action to control the selected state of JToggleButtons and JCheckBoxMenuItems from a single point.

Is that true?

Does anyone have a clever workaround?

Would this be a reasonable RFE?

I like the way Actions simplify enabling and disabling GUI elements, and this seemed to be a good idea for controlling the 'selected' or toggle state of GUI items as well.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
uncle_alice
Offline
Joined: 2003-06-16
Points: 0

As a matter of fact, a nice workaround was recently posted here on this site. Take a look at the source code accompanying [url=http://www.javadesktop.org/articles/actions/index.html]this article[/url]. Basically, you subclass AbstractAction to add support for a "selected" property; then, when you create a button/menuitem from the action, you add a separate PropertyChangeListener for that property.

As for the RFE, there have already been several submitted, and it looks like we're going to see some action on them in Tiger. I expect them to add support for the "selected" and "large-icon" properties at the very least. But if anyone has more detailed info about the planned changes, I'm dying to hear it!

swpalmer
Offline
Joined: 2003-06-10
Points: 0

Excellent, thanks!
I figured it would boil down to something along those lines, but it's nice to know that I wasn't missing something more obvious.

As for the rest of the article, I'm not big on the XML descriptions for generating UIs at runtime. Seems like you lose a lot of compiler checks developing that way.

uncle_alice
Offline
Joined: 2003-06-16
Points: 0

Yeah, XUL and such have never interested me much, either. But the article is only about creating the menus and toolbar(s) from config files, and I think that [i]is[/i] worthwhile. The author says it would allow a UI designer (someone other than the programmers) to decide what the best layout for menus and toolbars would be, and I think that's valid. But the next logical step is to provide a widget that lets the [i]user[/i] rearrange them (the toolbars, anyway) and then save the changes, just like you see in many text editors and office suites. That's a good thing to have, once the app gets beyond a certain level of complexity (or after the Marketing department gets its sticky little fingers on the UI). ;)