• Post Reply Bookmark Topic Watch Topic
  • New Topic

Selecting Font  RSS feed

 
Ryan O'Mara
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

 
Wayan Saryada
Ranch Hand
Posts: 119
Hibernate Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you tried to use the java.awt.Font class to set the font style?
 
Paul Clapham
Sheriff
Posts: 22835
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 62
5
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ryan O'Mara wrote:

Sorry, your approach to painting is wrong.

Please study how painting works in Swing: Lesson: Performing Custom Painting
 
Ryan O'Mara
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 22835
43
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2828
15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
  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
Sheriff
Posts: 22835
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2828
15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2828
15
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author
Ranch Hand
Posts: 959
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).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
Sheriff
Posts: 22835
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do they also teach people to use addActionListener(this)? Another
 
Brian Cole
Author
Ranch Hand
Posts: 959
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have multiple controls all sending events to the same action listaner, you end up with horrible code like:-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:-...you can lose about 80% of those keystrokes:-
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
Master Rancher
Posts: 2044
75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author
Ranch Hand
Posts: 959
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 4927
334
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!