GUI Problem

[Beth Laguardia]

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

public class SimpleGui3 implements ActionListener {
 
JFrame frame;

public static void main(String[] args) {

    SimpleGui3 guiThree = new SimpleGui3();
    guiThree.go();
 
}

public void go()
{
frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JButton button = new JButton("Change colors");

button.addActionListener(this);

MyDrawPanel panel = new MyDrawPanel();

frame.getContentPane().add(BorderLayout.SOUTH, button);
frame.getContentPane().add(BorderLayout.SOUTH, panel);
frame.setSize(500,500);
frame.setVisible(true);
}

public void actionPerformed(ActionEvent event)
{
frame.repaint();
}

public class MyDrawPanel extends JPanel {
 

public void paintComponent(Graphics g)
{
// Fill the entire panel with black
// The first 2 arguments defines the x,y upper let corner relative to the panel
g.fillRect(0,0,this.getWidth(), this.getHeight()); 

int red = (int) Math.random() * 255;
int green = (int) Math.random() * 255;
int blue = (int) Math.random() * 255;

Color randomColor = new Color(red, green, blue);
g.setColor(randomColor);
g.fillOval(70,70,100,100);
}
}
 





 
}
  

Here's the code from Head First Java, but it is not working on my Eclipse.
The output is wrong but there was no error only a warning in the code itself that says : The serialized class MyDrawPanel does not declare static final SerialVersionUID field type of long

I do not what does it mean!

Please help.

[Mark Vedder]

I'm not sure if you have gotten to the chapter in Head First that talks about Serialization of objects yet. Briefly, serialization is the writing or saving or an object to a file for example. Objects can be made to be serializable by extending the java.io.Serializable interface. Many of the Java Swing classes are serializable. When you make an object Serializable, you are suppose to put a private static final long property in the class named "SerialVersionUID". The value that you assign to this property is determined by a checksum formula. Java then uses the SerialVersionUID when deserializing an object to determine if the serialized version of the object is sufficiently compatible with the version of the class the object is trying to be serialized to. So its basically a version check.

At this point, I wouldn't worry too much about that warning; it will not affect your output at all. Later you can revisit the subject and learn more about it, including learning how you actually generate a SerialVersionUID value.

Now you mentioned the output you are getting is wrong. What output are you getting and what is expected?

[ Edit ]
Ok - I just ran the code you posted and I'm getting a blank frame. I'll take a look and let you know what I can determine.
[ July 27, 2008: Message edited by: Mark Vedder ]

[Rob Spoor]

Right click on the warning and choose to fix it. Choose a generated serialVersionUID. Presto.

While usually you want to generate a different serialVersionUID for each time you change anything in the class' signature, sometimes you want to retain compatibility with older versions. If the non-static non-transient fields themselves have not changed in name, type or order you will retain the compatibilty by using the same serialVersionUID. As said before, this will only work properly if the object can be (de)serialized in the same way.

Also something I just though about: if you do your own custom (de)serialization without using the default mechanism (i.e. you implement readObject and writeObject), you can always retain the same serialVersionUID as long as you write the same types in the same order.


You can also check your Eclipse settings and choose to ignore the missing serialVersionUID. That way the compiler will generate a new serialVersionUID each time you change the class enough.
[ July 27, 2008: Message edited by: Rob Prime ]

[Mark Vedder]

OK - I see the problem:

. . .
    frame.getContentPane().add(BorderLayout.SOUTH, button);
    frame.getContentPane().add(BorderLayout.SOUTH, panel);
. . .

The drawing panel is getting added on top of the button and is therefore covering it up. If you look at the frame when it runs, you will see a small black stripe at the bottom. That's the MyDrawPanel. Change the code so the panel is added to the CENTER:

. . .
    frame.getContentPane().add(BorderLayout.SOUTH, button);
    frame.getContentPane().add(BorderLayout.CENTER, panel);
. . .

Was that just a typo on your part (which we've all done) or is it wrong in the book?

[Mark Vedder]

The other thing I just noticed, is you need to modify your random color generation. Right now, it will always give you black, or a color with an RGB value of 0,0,0. The reason is this... Math.random() returns a double between 0 and 1. The int casting is happening before that value is getting multiplied by the 255. And based on the way int casting works, it will always cast to zero since it simply truncates. So you are always multiplying 0 and 255.

To fix, simply put the multiplication in parentheses so it happens before the casting:

int red = (int) (Math.random() * 255);

Do that for all three colors.

[ July 27, 2008: Message edited by: Mark Vedder ]

[Beth Laguardia]

Originally posted by Mark Vedder:
OK - I see the problem:

. . .
    frame.getContentPane().add(BorderLayout.SOUTH, button);
    frame.getContentPane().add(BorderLayout.SOUTH, panel);
. . .

The drawing panel is getting added on top of the button and is therefore covering it up. If you look at the frame when it runs, you will see a small black stripe at the bottom. That's the MyDrawPanel. Change the code so the panel is added to the CENTER:

. . .
    frame.getContentPane().add(BorderLayout.SOUTH, button);
    frame.getContentPane().add(BorderLayout.CENTER, panel);
. . .

Was that just a typo on your part (which we've all done) or is it wrong in the book?

Hey Sir Mark,

It was a wrong typo on my part. I am so sorry , I am embarrased, I am using two books so I mixed it up. But I understand now what is serialization. My proffessor have not teach us that, but we will have GUI the next meeting. Just trying to advance study..

Thanks for the help.

[Mark Vedder]

Glad to help. And no need to be embarrassed, and no need to apologize. There isn't a developer out there that hasn't made a typo at some point; and many of us make them daily ;0 The only reason I asked was that if it was wrong in the book, we'd want to file an errata report with them.

And we've all had cases where after spending hours trying to figure out why something doesn't work, upon calling someone else over to look at it, they see the problem in two seconds. That's why it is always good to ask for a second set of eyes. It's like proofreading something you wrote. Sometimes you are too close to the material to see the problems.

And kudos to you for reading ahead. You always get far more out of a lecture if you have seen the material beforehand.
[ July 28, 2008: Message edited by: Mark Vedder ]