Home » Archived » Visual Editor (VE) » Using javax.swing.ButtonGroup in VE
|
| Re: Using javax.swing.ButtonGroup in VE [message #11866 is a reply to message #11760] |
Thu, 18 December 2003 21:04   |
Eclipse User |
|
|
|
Originally posted by: jdm0532.nospam.cs.rit.edu
As far as I know there is no built-in support for working with
ButtonGroups yet. If it's any consolation, there's support for
java.awt.CheckBoxGroup :)
- Jeff
Ivan Bonilla wrote:
> Hi,
>
> I am having some trouble trying to use a set of RadioButton grouped into a
> ButtonGroup using the VE only.
>
> ¿Is there any way of doing this without coding directly?
>
> Thanks in advance, any help is very appreciated.
>
|
|
|
| Re: Using javax.swing.ButtonGroup in VE [message #12254 is a reply to message #11760] |
Fri, 19 December 2003 10:41 |
 Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Ivan,
> I am having some trouble trying to use a set of RadioButton grouped into a
> ButtonGroup using the VE only.
> ¿Is there any way of doing this without coding directly?
Not right now, but we should tool for it. Here are some ideas - let me know
what you think.
Right now we tool for AWT checkbox and checkboxGroup in the following way.
You drop down a bunch of java.awt.Checkbox and a java.awt.CheckboxGroup that
is a non-visual JavaBean. It sits on the canvas but away from the GUI
components because it has no visual component to it. The property sheet of
each Checkbox has the checkboxGroup property, and you can select from the list
of known checkbox groups (i.e. the ones that have been dropped onto the
canvas). This makes the association between the checkboxes that belong in the
same checkbox group giving them radio behavior.
We could do the same for ButtonGroup, so each AbstractButton subclass had a
property called buttonGroup. This gave you a list of all of the known
ButtonGroup classes and you made the association as for AWT.
The subtle difference with this and how AWT works is that in AWT the code is
checkbox.setCheckboxGroup(getCheckboxGroup1():
whereas in Swing it's the other way around
buttonGroup.add(getOKButton());
Having the Swing target of the method be the buttonGroup sort of implies to me
that you go to the button group and visually add the buttons to it, rather
than the other way around. The way we usually do this for other relationships
like Container/Components or JSplitPane/panes is with containment in the tree
or visually. You drop the child onto the parent to get an add(...) type
method created. The button however already belongs to the parent Swing
container, so it's like it now has two parents. We could maybe have it so you
drop the ButtonGroup down and drag buttons into it (either on the tree of
graphical view) but instead of these being re-parented they are just now
associated with the button group. Then we have the problem of how to show the
user that this association exists. If we show extra children on the tree the
this might be odd because it's done anywhere else, and what does "delete" mean
- does it mean remove from the group or remove it altogether ? VisualAge for
Java had a nice feature called connections, and maybe the solution is
something along these lines where you select the buttonGroup/checkboxGroup and
you can see lines drawn from it to all of the buttons that it owns. Maybe
instead of lines the children are just highlighted differently and there is a
way of putting the cursor into a mode where you can select and de-select them
in and out of the group.
Either way - it's a design discussion we should have to find a good solution,
for what works well for this is applicable to other similar kinds of
association. Please enter a bugzilla feature request.
In the meantime one thing I have seen done that works well is to create your
own JavaBean that is a subclass of JPanel that has a ButtonGroup as a private
field and specialize the method something like
protected void addImpl(Component comp, Object constraints, int index) {
super.addImpl(comp,constraints,index);
myButtonGroup.add(comp);
}
Do likewise for the removeImpl method, and what you now have is effectively a
group box panel. You could then add this down using Choose Bean on the
palette.
I think Scott Stanchfield once had a set of good Swing helper classes
including this kind of encapsulated ButtonGroup container, as well as some
other nice goodies for BoxLayout and stuff.
Best regards,
Joe Winchester
|
|
|
| Re: Using javax.swing.ButtonGroup in VE [message #12277 is a reply to message #12254] |
Fri, 19 December 2003 14:38 |
Scott Stanchfield
Messages: 263
Registered: July 2009 |
Senior Member |
|
|
I was about to mention the same concept ;)
I started writing a set of Swing Helpers, which did some interesting
stuff. One of them was a radio button panel like this.
The only thing I see in my CVS repos is unfinished. (It included some
same-size-group concepts to assist layout management and helpers like
this one.)
The only difference between what I have and Joe suggested is that I
checked to see if the thing being added was a radio button (for more
general use, I'd suggest checking JToggleButton):
private ButtonGroup group = new ButtonGroup();
protected void addImpl(
Component comp, Object constraints, int index) {
super.addImpl(comp, constraints, index);
if (Beans.isInstanceOf(comp, JToggleButton.class))
group.add((JRadioButton) comp);
}
I also had this same class extend what I called an "enabling panel". The
enabling panel was able to enable/disable all of its components. The
only change to make it an enabling panel is:
public void setEnabled(boolean value) {
super.setEnabled(value);
Component comps[] = getComponents();
for (int i = 0; i < comps.length; i++)
comps[i].setEnabled(value);
validate();
}
(don't know if anyone needs this, but food for thought...)
In case anyone is wondering, the same-size-group concept is similar to
the button group concept, but drives the preferred size of a component.
(This allows components in different layouts to report the same
preferred size, removing the need for the evil BarfBagLayout)
I just whipped up a quick sample and posted it at
http://javadude.com/misc/samesize.html
Sorry for the lack of comments but I'm pressed for time, but I thought
the concept might be interesting for folks to see... When running the
sample, press the "A" button and watch what happens to the labels in the
two borderlayouts...
Later,
-- Scott
In article <3FE2D5D6.6091BFEA@uk.ibm.com>, winchest@uk.ibm.com says...
> In the meantime one thing I have seen done that works well is to create your
> In the meantime one thing I have seen done that works well is to create your
> own JavaBean that is a subclass of JPanel that has a ButtonGroup as a private
> field and specialize the method something like
>
> protected void addImpl(Component comp, Object constraints, int index) {
> super.addImpl(comp,constraints,index);
> myButtonGroup.add(comp);
> }
>
> Do likewise for the removeImpl method, and what you now have is effectively a
> group box panel. You could then add this down using Choose Bean on the
> palette.
> I think Scott Stanchfield once had a set of good Swing helper classes
> including this kind of encapsulated ButtonGroup container, as well as some
> other nice goodies for BoxLayout and stuff.
|
|
| | |
| Re: Using javax.swing.ButtonGroup in VE [message #575454 is a reply to message #11760] |
Fri, 19 December 2003 10:41 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Ivan,
> I am having some trouble trying to use a set of RadioButton grouped into a
> ButtonGroup using the VE only.
> ¿Is there any way of doing this without coding directly?
Not right now, but we should tool for it. Here are some ideas - let me know
what you think.
Right now we tool for AWT checkbox and checkboxGroup in the following way.
You drop down a bunch of java.awt.Checkbox and a java.awt.CheckboxGroup that
is a non-visual JavaBean. It sits on the canvas but away from the GUI
components because it has no visual component to it. The property sheet of
each Checkbox has the checkboxGroup property, and you can select from the list
of known checkbox groups (i.e. the ones that have been dropped onto the
canvas). This makes the association between the checkboxes that belong in the
same checkbox group giving them radio behavior.
We could do the same for ButtonGroup, so each AbstractButton subclass had a
property called buttonGroup. This gave you a list of all of the known
ButtonGroup classes and you made the association as for AWT.
The subtle difference with this and how AWT works is that in AWT the code is
checkbox.setCheckboxGroup(getCheckboxGroup1():
whereas in Swing it's the other way around
buttonGroup.add(getOKButton());
Having the Swing target of the method be the buttonGroup sort of implies to me
that you go to the button group and visually add the buttons to it, rather
than the other way around. The way we usually do this for other relationships
like Container/Components or JSplitPane/panes is with containment in the tree
or visually. You drop the child onto the parent to get an add(...) type
method created. The button however already belongs to the parent Swing
container, so it's like it now has two parents. We could maybe have it so you
drop the ButtonGroup down and drag buttons into it (either on the tree of
graphical view) but instead of these being re-parented they are just now
associated with the button group. Then we have the problem of how to show the
user that this association exists. If we show extra children on the tree the
this might be odd because it's done anywhere else, and what does "delete" mean
- does it mean remove from the group or remove it altogether ? VisualAge for
Java had a nice feature called connections, and maybe the solution is
something along these lines where you select the buttonGroup/checkboxGroup and
you can see lines drawn from it to all of the buttons that it owns. Maybe
instead of lines the children are just highlighted differently and there is a
way of putting the cursor into a mode where you can select and de-select them
in and out of the group.
Either way - it's a design discussion we should have to find a good solution,
for what works well for this is applicable to other similar kinds of
association. Please enter a bugzilla feature request.
In the meantime one thing I have seen done that works well is to create your
own JavaBean that is a subclass of JPanel that has a ButtonGroup as a private
field and specialize the method something like
protected void addImpl(Component comp, Object constraints, int index) {
super.addImpl(comp,constraints,index);
myButtonGroup.add(comp);
}
Do likewise for the removeImpl method, and what you now have is effectively a
group box panel. You could then add this down using Choose Bean on the
palette.
I think Scott Stanchfield once had a set of good Swing helper classes
including this kind of encapsulated ButtonGroup container, as well as some
other nice goodies for BoxLayout and stuff.
Best regards,
Joe Winchester
|
|
|
| Re: Using javax.swing.ButtonGroup in VE [message #575554 is a reply to message #12254] |
Fri, 19 December 2003 14:38 |
Scott Stanchfield
Messages: 263
Registered: July 2009 |
Senior Member |
|
|
I was about to mention the same concept ;)
I started writing a set of Swing Helpers, which did some interesting
stuff. One of them was a radio button panel like this.
The only thing I see in my CVS repos is unfinished. (It included some
same-size-group concepts to assist layout management and helpers like
this one.)
The only difference between what I have and Joe suggested is that I
checked to see if the thing being added was a radio button (for more
general use, I'd suggest checking JToggleButton):
private ButtonGroup group = new ButtonGroup();
protected void addImpl(
Component comp, Object constraints, int index) {
super.addImpl(comp, constraints, index);
if (Beans.isInstanceOf(comp, JToggleButton.class))
group.add((JRadioButton) comp);
}
I also had this same class extend what I called an "enabling panel". The
enabling panel was able to enable/disable all of its components. The
only change to make it an enabling panel is:
public void setEnabled(boolean value) {
super.setEnabled(value);
Component comps[] = getComponents();
for (int i = 0; i < comps.length; i++)
comps[i].setEnabled(value);
validate();
}
(don't know if anyone needs this, but food for thought...)
In case anyone is wondering, the same-size-group concept is similar to
the button group concept, but drives the preferred size of a component.
(This allows components in different layouts to report the same
preferred size, removing the need for the evil BarfBagLayout)
I just whipped up a quick sample and posted it at
http://javadude.com/misc/samesize.html
Sorry for the lack of comments but I'm pressed for time, but I thought
the concept might be interesting for folks to see... When running the
sample, press the "A" button and watch what happens to the labels in the
two borderlayouts...
Later,
-- Scott
In article <3FE2D5D6.6091BFEA@uk.ibm.com>, winchest@uk.ibm.com says...
> In the meantime one thing I have seen done that works well is to create your
> In the meantime one thing I have seen done that works well is to create your
> own JavaBean that is a subclass of JPanel that has a ButtonGroup as a private
> field and specialize the method something like
>
> protected void addImpl(Component comp, Object constraints, int index) {
> super.addImpl(comp,constraints,index);
> myButtonGroup.add(comp);
> }
>
> Do likewise for the removeImpl method, and what you now have is effectively a
> group box panel. You could then add this down using Choose Bean on the
> palette.
> I think Scott Stanchfield once had a set of good Swing helper classes
> including this kind of encapsulated ButtonGroup container, as well as some
> other nice goodies for BoxLayout and stuff.
|
|
| |
Goto Forum:
Current Time: Sat Dec 21 16:13:03 GMT 2024
Powered by FUDForum. Page generated in 0.04576 seconds |
] 
Search
Help
Register
Login
Home
