Selecting Font

[Ryan O'Mara]

I have just finished my class test and I did everything apart from the last bit which is for the user to type in a font style and then anything written on the JPanel is written in that style. We have not covered this in the lectures, so don't really know where to start.

Below is the code:

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

 
public class classTest extends JFrame
                     implements ActionListener {
    
     private JPanel panel;
     private JTextField text;
     private JTextField font;
     private JTextField amount;
     private JLabel textLabel;
     private JLabel fontLabel;
     private JLabel amountLabel;
     private JButton button;
     private int numberOfTimes;
     Font Font1 = new Font( "", Font.BOLD, 12 );
     
    
     public static void main(String[] args ) {
          
           classTest frame = new classTest();
           frame.setSize( 500, 700 );
           frame.createGUI();
           frame.setVisible( true );
          
     }
    
     private void createGUI() {
          
           setDefaultCloseOperation( EXIT_ON_CLOSE );
           Container window = getContentPane();
           window.setLayout( new FlowLayout() );
          
           text = new JTextField(5);
           textLabel = new JLabel( "Enter Text:" );
           window.add( textLabel );
           window.add( text );
          
           button = new JButton( "Press Me" );
           window.add( button );
           button.addActionListener( this );
          
           amount = new JTextField( 5 );
           amountLabel = new JLabel( "Amount:" );
           window.add( amountLabel );
           window.add( amount );
          
           font = new JTextField( 5 );
           fontLabel = new JLabel( "Font:" );
           window.add( fontLabel );
           window.add( font );
          
           panel = new JPanel();
           panel.setBorder( BorderFactory.createMatteBorder( 4,  4,  4,  4, Color.green ) );
           panel.setPreferredSize( new Dimension( 400, 400 ) );
           panel.setBackground( Color.pink );        
           window.add( panel );
          
     }
 
     public void actionPerformed( ActionEvent e ) {
          
           Graphics g = panel.getGraphics();
           paintScreen(g);
           drawText( g );
           
     }
          
     public void drawText( Graphics g ) {
          
           try {
        	   
                numberOfTimes = Integer.parseInt( amount.getText() );
                int count = 0;
                int x = 30;
                int y = 30;
           
                while ( count < numberOfTimes ) {
                g.drawString( text.getText(), x, y );
                y = y + 30;
                count++;
                }
           }
           
           catch (NumberFormatException e ) {
                g.setColor(Color.red);
                g.drawString( "Enter Number", 50, 40);
           }
     }
 
     public void paintScreen( Graphics g ) {
          
           g.setColor( Color.pink );
           g.fillRect( 20, 20, 370, 370 );
           g.setColor( Color.black );
          
     }
}

[I Wayan Saryada]

Have you tried to use the java.awt.Font class to set the font style?

[Paul Clapham]

And once you have made a Font object from the input data, you'll need to call setFont() on the Graphics object. It's best to do that in the paintComponent() method -- in fact, it's best to call the drawText() method from paintComponent() as well.

Oh... I see you haven't overridden paintComponent(). You should be overriding the JPanel's paintComponent() method with the code you have in your paintScreen() method. You shouldn't be drawing on the JPanel from your code, you should be drawing from Swing's code. That would be Swing's paintComponent() method. Hopefully the code you posted wasn't based on what you were taught in the course!

By the way, you mentioned that the user would be typing a "font style". That means one of BOLD, ITALIC, or PLAIN... so having the user type one of those things would be sort of clumsy. Choosing from a JList would be more convenient for the user. Or did you mean for the user to type a font name, like Helvetia or Comic Sans?

[Andrea Binello]

Ryan O'Mara wrote:

     public void actionPerformed( ActionEvent e ) {
          
           Graphics g = panel.getGraphics();
           paintScreen(g);
           drawText( g );
           
     }

Sorry, your approach to painting is wrong.

Please study how painting works in Swing: Lesson: Performing Custom Painting

[Ryan O'Mara]

Paul Clapham wrote:And once you have made a Font object from the input data, you'll need to call setFont() on the Graphics object. It's best to do that in the paintComponent() method -- in fact, it's best to call the drawText() method from paintComponent() as well.

Oh... I see you haven't overridden paintComponent(). You should be overriding the JPanel's paintComponent() method with the code you have in your paintScreen() method. You shouldn't be drawing on the JPanel from your code, you should be drawing from Swing's code. That would be Swing's paintComponent() method. Hopefully the code you posted wasn't based on what you were taught in the course!

By the way, you mentioned that the user would be typing a "font style". That means one of BOLD, ITALIC, or PLAIN... so having the user type one of those things would be sort of clumsy. Choosing from a JList would be more convenient for the user. Or did you mean for the user to type a font name, like Helvetia or Comic Sans?

Yes that is the way we have been taught we are learning the other way next semester. Also it for the user to input Comic Sans, Times Roman etc....

[Paul Clapham]

Oh dear. I really hate those courses which teach you the wrong way to code but promise to teach you the right way later. Especially when the wrong way isn't easier than the right way.

So I can't really help you. I know how to do it the right way (see Andrea Binello's post) but I have no idea how to do it in your course's wrong way.

[Rob Camick]

 Yes that is the way we have been taught  

I sure hope not:

1. class names should start with an upper case character.
2. never use getGrraphics() of a component to do custom painting. Don't believe me try clicking your button and then resizing the JFrame and watch the painting magically disappear. Actually it's not magic, it's because the is NOT the way to do painting.

[Paul Clapham]

Extending JFrame and then ignoring that and creating a new JFrame to use for the GUI is another faux pas in that code. Not to mention having the main class implement ActionListener, instead of creating an ActionListener object where it's actually needed; people realized that composition was preferable to inheritance in this case well over a decade ago.

[Ryan O'Mara]

Paul Clapham wrote:Extending JFrame and then ignoring that and creating a new JFrame to use for the GUI is another faux pas in that code. Not to mention having the main class implement ActionListener, instead of creating an ActionListener object where it's actually needed; people realized that composition was preferable to inheritance in this case well over a decade ago.

Is there anywhere on the internet to learn the other way?

[Rob Camick]

Is there anywhere on the internet to learn the other way?

You were already given a link to the Swing tutorial on Custom Painting. Did you read it and download the demo code?

The code there shows how to do proper painting and is doesn't extend JFrame so it is definitely a place to start which is why you were given the link in the first place.

I'm not going to suggest that all the tutorial code is perfect, but is sure much better that what you appear to be getting from your teacher.

[Ryan O'Mara]

The way that it says to write code on the website given is different from the way we have been taught. we have been using the book Java for students and that doesn't mention super.paintComponent and even does the code the way I have been doing.

[Rob Camick]

I'm not sure what the point of your last comment was.

You have already been told the way you have been taught is wrong. You can continue the wrong way or learn the correct way but we are not going to spend time helping if you don't want to learn how to do it properly.

Did you try my earlier suggestion to click the button and see the text appear and then resize the frame to see the text disappear?

That should be evidence enough that your approach is wrong.

I suggest you need to talk to your classmates for future help because we can't possibly guess what you are being taught.

[Brian Cole]

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.

[Paul Clapham]

Well, on Amazon:

The authors wrote:We wanted to make sure that the fun element of programming was paramount, so we use graphics right from the start. We think graphics is fun, interesting and clearly demonstrates all the important principles of programming.

I think that making it fun to learn a programming language is a great goal -- it's just a pity that they have to do it in such a way that the students have to unlearn Chapter 3 once they get further through the book.

[Campbell Ritchie]

Brian Cole wrote:. . . I found a table of contents for the 5th edition . . . There are also downloadable code examples and. . .

. . . a link for ppt files for instructors. These have the same abomination for chapter 3.

[Campbell Ritchie]

Do they also teach people to use addActionListener(this)? Another

[Brian Cole]

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.

[Stephan van Hulst]

Not merely clunky. It means you can add your form as an action listener on a button on a completely unrelated form, likely with very unpredictable results.

[Campbell Ritchie]

If you have multiple controls all sending events to the same action listaner, you end up with horrible code like:-

// ...
@Override
public void actionPerformed(ActionEvent evt)
{
   if (evt.getSource() == button1)
   {
      something();
   }
   else if (evt.getSource() == button2)
   {
      somethingDifferent();
   }
   else if (evt.getSource() == button3)
   {
      somethingElse();
   }
   // ... etc
}

That is going to be error‑prone if you ever need to change anything, and you cannot be confident that every button has a corresponding path via a listener to its required action.
Anonymous classes might look ugly, but you get one listener per action required. You can write private classes or public classes for instances where several listeners do the same thing. At least that is an object‑oriented design, whereas the repeated if‑elses look very procedural to me. BC is right that a λ will look so much better. Rather than writing this sort of thing:-

saveToFileButton.addActionListener(
   new ActionListener()
   {
      @Override
      public void actionPerformed(ActionEvent evt)
      {
         saveToFile(...);
      }
   }
);

...you can lose about 80% of those keystrokes:-

saveToFileButton.addActionListener(evt ->  saveToFile(...));

Stephan van Hulst wrote:. . . you can add your form as an action listener on a button on a completely unrelated form . . .

If you have all your components as local variables, at least that can't happen without your knowing it. Another argument for not writing
public class MyGUI extends JFrame implements ActionListener

[Piet Souris]

I always love the way you guys put in the nuances in your replies. Never do ..., always do ...,  tearing a book apart without knowing much about the context, need I go on?

Well, I've used the'direct drawing method' myself a couple of times, with excellent result, I used 'implements ActionListener' myself in the past, and it was only about 4 years ago that I learned about the EDT. I wonder how I survived all this.

[Brian Cole]

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.

[Liutauras Vilda]

Even broken watch twice a day shows correct time.

I think the guys here are concerned about the rest of the moments.

But knowing Piet, I see his point.

Anyway, OP knows by now two approaches.

[Stephan van Hulst]

Piet Souris wrote:Well, I've used the'direct drawing method' myself a couple of times, with excellent result, I used 'implements ActionListener' myself in the past, and it was only about 4 years ago that I learned about the EDT. I wonder how I survived all this.

It's not about surviving. I assume that most people want to learn to program so they can write code that can be reused by others. I have to maintain a huge pile of code that I have to patch up all the time, because it's built on top of stuff that used "simple methods with excellent result".

Quick hacks are fine if you want to implement a simple use case, and if it doesn't make your work harder in the long run. Learning quick hacks before you learn the proper way is not fine.

[Campbell Ritchie]

Piet Souris wrote:. . . tearing a book apart without knowing much about the context, need I go on? . . .

You obviously prefer people to get paid for teaching wrong programming practice