Brian Cole

BTW you can add JCheckBoxes to a ButtonGroup if you want, to answer the original question. But I agree that from a UI perspective JRadioButtons make more sense.

Have you tried experimenting with myButton.setContentAreaFilled(true) yet?
It may be that Netbeans is using a different look and feel, or something like that, which is setting this property differently.

If you perform this search it will return a bunch of hits.

At the time I'm writing this, the first hit is this thread. The second is https://coderanch.com/p/3268303 which interestingly has a capital Y in the excerpt on the search result page, but the Y is lower case if you follow the link and look at the page itself.

Same deal for  and https://coderanch.com/p/3268176 and https://coderanch.com/p/3268005 . Both of those show capital Y in the search results excerpts and lower-case Y on the post themselves. Obviously they should be capitalized, since they start sentences.

It seems that there is some code that looks for "you should" and creates a hyperlink to http://www.permies.com/t/36936/tnk/

That's fine, I guess, but there seems to be a bug where it replaces "You should" (with a capital 'Y)' to "you should" (with a lower-case 'y'). The result is that it looks like I've made an editorial mistake in my post, when I haven't. (Or rather, there are probably plenty of editorial mistakes, but this particular sentence that begins with a lower-case letter was not one of them.)

I tried to post this to the actual thread at http://www.permies.com/t/36936/tnk/ but I don't seem to have an account on that site.

Luke jaryszek wrote:But with this text pane i should have only place for 4 digits. (number from 1 to 100).

There are a couple of issues here, but IMHO the fundamental one is that setBounds() and setSize() simply do not work to set a component's size. That's because the container's LayoutManager that is automatically in place will clobber any size/bounds you might have tried to set. (If you're not using a LayoutManager at all, then those two methods will work, but it is not recommended to not use a LayoutManager except by experts who know what they are doing, and even then only rarely. The rest of this posting assumes that a LayoutManager is in place.)

A method that does work is setPreferredSize(). It's fine if you want to use setPreferredSize(), but Swing's text components generally provide simpler ways of setting size.

JTextPane doesn't, but the only reason to use JTextPane is if you want to handle text in different styles (such as some text in one font and some text in a different font). If you want text in a single style, you could use JTextArea, which has constructors which take rows and columns paramaters: new TextArea(1, 8) Or there are separate setRows() and setColumns() methods. But JTextArea only makes sense if you need to support multiple rows of text.

For a single-row text field you can use JTextField, which has constructors which take a columns parameter: new TextField(4) Or it has a setColumns() method. Or you might want to use a JSpinner instead of a JTextField.

minor footnote: With JTextField you sometimes must to set more columns than you actually need. That's because it sets the required text-width for the whole component, including its borders, but the left and right borders cut into the usable width. This is stupid, but it's been that way for decades and isn't going to change now.

Campbell Ritchie wrote:Does that code compile without event -> ?

Are you asking about my code or Mr. Souris's code?

My code needs something to replace the "...". It could be a call to a constructor of a named class, or an anonymous subclass, or something like "event -> someMethod()" (as you suggest).

The method reference expressions Mr. Souris uses should be fine, presuming you have java8 or later. They are more or less interchangable with lambdas.

Scott Eric Catalano wrote:So to re-iterate my question. The JButton and JMenuItem need to call the same Action Listener.

You can do something like this:ActionListener myListener = ...; // create your listener any way you want myButton.addActionListener(myListener); myMenuItem.addActionListener(myListener);Then they will both invoke the same listener no matter where you place them.


However that's probably not the way I would do it. I would usually create an instantiation of javax.swing.Action and pass it to the JButton and JMenuItem constructors:Action myAction = ...; JButton myButton = new JButton(myAction); JMenuItem myMenuItem = new JMenuItem(myAction);This is slightly more work but can be cleaner. (ActionExample)

Glen Chamisa wrote:It seems even when I use BI_RLE4, I get the same issue. However, with the other string types, BI_RGB and BI_BITFIELDS the program runs fine. Can someone explain this cos I don't understand the problem.

I don't know a whole lot about the BMP format, but the javadoc for javax.imageio.plugins.bmp.BMPImageWriteParam says, "If the specified compression scheme is not compatible with the type of image being written then the IOException will be thrown by the BMP image writer." It sounds like this is happening.

You might want to try calling getCompressionTypes() on your BMPImageWriteParam and examine what it returns. I can't say for sure that this would be helpful, but it might be.

peter m hayward wrote:can you expand upon the Never do I/O in a renderer

Because I/O is slow and renderers are intended to be fast. And even if I/O weren't slow, it would still be wasteful to call createImageIcon() more than once per image. And a renderer can and will be called many many times for each item in your list.

Mr. Camick's suggestion to make type of your ComboBox be a compound object that holds both text and an icon is sound. That's a good solid way to write your program.

Here's another way, where the type of the ComboBox can remain a simple String: public class MappedIconRenderer extends DefaultListCellRenderer {    private Map<?, ? extends Icon> map;        public MappedIconRenderer(Map<?, ? extends Icon> iconMap) {        map = iconMap;    }    @Override    public Component getListCellRendererComponent(JList<?> list, Object value, int index, boolean isSelected, boolean cellHasFocus) {        Component c = super.getListCellRendererComponent(list, value, index, isSelected, cellHasFocus);        setIcon(map.get(value)); // might be passing null as the Icon, which would be fine        return c; // or: return this; (c and this are the same object)    }        private static final long serialVersionUID = 1L; }

This way you load all your images up front, like this: Map<String, Icon> iconMap = new HashMap<>(); iconMap.put("hardback", createImageIcon("file:///C:/images/hardback.gif")); iconMap.put("paperback", ...); ... bindings.setRenderer(new MappedIconRenderer(iconMap));

peter m hayward wrote:can you expand upon the Never do I/O in a renderer

Because I/O is slow and renderers are intended to be fast. And even if I/O weren't slow, it would still be wasteful to call createImageIcon() more than once per image. And a renderer can and will be called many many times for each item in your list.

Mr. Camick's suggestion to make type of your ComboBox be a compound object that holds both text and an icon is sound. That's a good solid way to write your program.

Here's another way, where the type of the ComboBox can remain a simple String:
public class MappedIconRenderer extends DefaultListCellRenderer { private Map<?, ? extends Icon> map; public MappedIconRenderer(Map<?, ? extends Icon> iconMap) { map = iconMap; } @Override public Component getListCellRendererComponent(JList<?> list, Object value, int index, boolean isSelected, boolean cellHasFocus) { Component c = super.getListCellRendererComponent(list, value, index, isSelected, cellHasFocus); setIcon(map.get(value)); // might be passing null as the Icon, which would be fine return c; // or: return this; (c and this are the same object) } private static final long serialVersionUID = 1L; }
This way you load all your images up front, like this:
Map<String, Icon> iconMap = new HashMap<>(); iconMap.put("hardback", createImageIcon("file:///C:/images/hardback.gif")); iconMap.put("paperback", ...); ... bindings.setRenderer(new MappedIconRenderer(iconMap));

Paul Clapham wrote:    setLayout(new GridLayout(4, 1));This creates a layout with 4 rows and 1 column. Since you want 2 columns then the second parameter ought to be 2, not 1. And the first parameter ought to be however many rows you want.

At the risk of being irrelevant to the original poster, allow me to elaborate on this a bit.

If you look at how GridLayout is actually implemented, then you will see that new GridLayout(4, 1) will actually lay out with 4 rows and with as many columns as necessary. The cols argument is essentially ignored. (If you doubt, the javadocs for the GridLayout.setColumns() method explains this. Or just run a few quick examples and you'll see.)

Because of this, when I use GridLayout I always specify zero either for rows or for cols, just to remind myself how GridLayout works. So I would write either new GridLayout(n, 0) or new GridLayout(0, n). In this case, in which a two-column grid seems to be desired, I would use new GridLayout(0, 2).

Three things:
1) This was cross-posted to stackoverflow. http://stackoverflow.com/questions/47528136/

2) It is a mistake to append System.getProperty("line.separator"). You should simply be appending "\n" because that's how all Swing text components represent it internally. Any line-ending conversions that might be needed happen elsewhere, such as in textArea.write().

3) If the body of the DocumentListener were { Unregister the listener; Append the newline (directly, not via invokeLater) ; Register the listener back again; } then you would not see the looping behavior. That's not a good way to actually implement it, but as an example it can help demonstrate what's going on. A good way would be via DocumentFilter, which was designed exactly for this kind of thing.

Piet Souris wrote:Well, I've used the'direct drawing method' myself a couple of times, with excellent result,

Was it due to the same book, or something else? I ask because I've always thought that JComponent.getGraphics() was (and should be) an obscure method that wasn't widely known.

Campbell Ritchie wrote:Do they also teach people to use addActionListener(this)? Another

I'm not as disapproving of this as some people. Yes, it's ugly, but to some extent so is creating an inner or anonymous class to be the listener.
If one can presume that lambda expressions are allowed (they have been available for 3½ years now) then I would suggest addActionListener( e -> something );

But I think we can agree (?) that the ActionListener part of this code isn't as bad as the getGraphics part of this code. I wouldn't even say using addActionListener(this) is incorrect, but merely clunky.

Ryan O'Mara wrote:we have been using the book Java for students

Java for Students (6th ed), Douglas Bell and Mike Parr, 2010, Pearson Education Canada
Java for Students (5th ed), Douglas Bell and Mike Parr, 2006, Prentice Hall

I found a table of contents for the 5th edition on the web. It lists chapter 3 as "Using graphics methods," which is pretty darn early in the book. It's before chapters on methods (chapter 5), conditionals (7), loops (8), classes (9), and inheritance (10).

There are also downloadable code examples and, sure enough, chapter three includes this example (and others which are similar).import java.awt.*; import java.awt.event.*; import javax.swing.*; public class DrawCircle extends JFrame    implements ActionListener {    private JButton button;    private JPanel panel;    public static void main(String[] args) {        DrawCircle frame = new DrawCircle();        frame.setSize(400, 300);        frame.createGUI();        frame.setVisible(true);    }    private void createGUI() {        setDefaultCloseOperation(EXIT_ON_CLOSE);        Container window = getContentPane();        window.setLayout(new FlowLayout() );        panel = new JPanel();        panel.setPreferredSize(new Dimension(300, 200));        panel.setBackground(Color.white);        window.add(panel);        button = new JButton("Press me");        window.add(button);        button.addActionListener(this);    }    public void actionPerformed(ActionEvent event) {        Graphics paper = panel.getGraphics();        paper.drawOval(0, 0, 100, 100);    } }There are plenty of things to quibble about here. It's not creating the GUI on the EDT*, which was normal before 2004, so maybe not a ding against this 2006 book. There's no real reason to extend JFrame here, especially since inheritance isn't until chapter 10, but no biggie. I guess I can accept implementing ActionListener (as opposed to having to declare another class, nested or otherwise) in chapter 3 of an introductory book. Why give the JPanel a preferred size when you could put it in the CENTER of a BorderLayout? Why is it calling the content pane "window" when that term usually means something else? And why use a JPanel when a JComponent would do just as well?

But calling panel.getGraphics().drawOval() in the ActionListener is pretty bad. Perhaps the authors knew it was bad and were just trying to construct a graphical program simple enough to appear in chapter 3 of an introductory book, but I don't think that's a valid excuse for this code. For one thing, this code is drawing this circle only transiently. If the program's frame is redrawn for any reason (perhaps because it was temporarily obscured by another window) then the circle will disappear until the user clicks the button again. So not only was this code not written the way Sun/Oracle says it should be, which should be enough for most of us, but this program flat out doesn't behave correctly.

It's a shame that there are so many books out there that are wrong. They do a disservice to the students who try to use them. And it's no fun for those trying to give good advice on forums such as CodeRanch.

footnote: *My book doesn't create the GUI on the EDT either. However it was published in 2002, before the swing single threading rule quietly changed.