Strange problem with a JFrame

[Passero]

When i load my program i get an empty pane and when i resize the JFrame, i
get my JButton on the screen. I don't see where the problem is, i use to do
it on that way and it always worked...
Can someone see the problem?

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

public class Hoofdscherm extends JFrame
{
private Beheerder deBheerder;
private JButton btnMatrixVolledig, btnMatrixVariabelen, btnMatrixVgl;

public Hoofdscherm(Beheerder deBeheerder)
{
super("SimplexMethode");
this.deBheerder = deBeheerder;
ActionEventHandler handler = new ActionEventHandler();

Container c = getContentPane();
c.setLayout(new FlowLayout());

btnMatrixVolledig = new JButton("Volledige matrix ingeven");
btnMatrixVolledig.addActionListener(handler);
c.add(btnMatrixVolledig);

setVisible(true);
setBounds(0,0,800,600);
}

private class ActionEventHandler implements ActionListener
{
public void actionPerformed(ActionEvent e)
{

}
}
}

 

[Passero]

Here's the solution:

I have to write:

setBounds(0,0,800,600);
setVisible(true);

instead of first setVisible and then setBounds....
I really don't get it

 

[johnR]

When i load my program i get an empty pane and when i

resize the JFrame, i get my JButton on the screen. I don't
see where the problem is, i use to do it on that way and it
always worked...
Can someone see the problem?

It works for me after I swapped the following
lines like this :

setBounds(0,0,800,600);
setVisible(true);

 

[johnR]

setBounds(0,0,800,600);

setVisible(true);

instead of first setVisible and then setBounds....
I really don't get it

Well, the button can only be placed after the size of the
panel is known.
And setVisible() just paints the screen (with or without
the button).

 

[Andrew Thompson]

When i load my program i get an empty pane and when i resize the JFrame, i
get my JButton on the screen. I don't see where the problem is, i use to do
it on that way and it always worked...
Can someone see the problem?

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

public class Hoofdscherm extends JFrame
{
// private Beheerder deBheerder;
private JButton btnMatrixVolledig, btnMatrixVariabelen, btnMatrixVgl;

// public Hoofdscherm(Beheerder deBeheerder)
public Hoofdscherm()
{
super("SimplexMethode");
// this.deBheerder = deBeheerder;
ActionEventHandler handler = new ActionEventHandler();

Container c = getContentPane();
c.setLayout(new FlowLayout());

btnMatrixVolledig = new JButton("Volledige matrix ingeven");
btnMatrixVolledig.addActionListener(handler);
c.add(btnMatrixVolledig);

pack();
setVisible(true);
setBounds(0,0,800,600);
}

private class ActionEventHandler implements ActionListener
{
public void actionPerformed(ActionEvent e)
{

}
}

public static void main(String[] args)
{
Hoofdscherm h = new Hoofdscherm();
}
}

1) You need to improve your 'small self contained,
compileable example' style, I had to comment
out various lines and add a main.

2) Learn some Layout managers, you may be
usedf to AWT where default llayout was FlowLayout,
but in Swing it is BorderLayout, does not go down
well with adding multiple components the way you
added the button.

HTH

 

[Jon A. Cruz]

Passero wrote:
public class Hoofdscherm extends JFrame

{
private Beheerder deBheerder;
private JButton btnMatrixVolledig, btnMatrixVariabelen, btnMatrixVgl;

public Hoofdscherm(Beheerder deBeheerder)
{
....

setVisible(true);
setBounds(0,0,800,600);
}

There are two problems with that.

1) You should not set visible from within a constructor.


Hoofdscherm tmp = new Hoofdscherm( thing );
tmp.pack();
tmp.show();


2) You should not be explicitly setting bounds on a JFrame. Instead call
pack() on it. Leave the numbers up to layout managers.

 

[Andrew Thompson]

| Passero wrote:
| public class Hoofdscherm extends JFrame
| > {
| > private Beheerder deBheerder;
| > private JButton btnMatrixVolledig, btnMatrixVariabelen,
btnMatrixVgl;
| >
| > public Hoofdscherm(Beheerder deBeheerder)
| > {
| ...
|
| > setVisible(true);
| > setBounds(0,0,800,600);
| > }
| >
|
| There are two problems with that.
|
| 1) You should not set visible from within a constructor.

Why? [ I do it almost invariably.. ]

[ but note that I am also doing work in AWT,
for which Component.show was deprecated in 1.1.. ]

 

[Jon A. Cruz]

| Passero wrote:
| public class Hoofdscherm extends JFrame
| > {
| > private Beheerder deBheerder;
| > private JButton btnMatrixVolledig, btnMatrixVariabelen,
btnMatrixVgl;
| >
| > public Hoofdscherm(Beheerder deBeheerder)
| > {
| ...
|
| > setVisible(true);
| > setBounds(0,0,800,600);
| > }
| >
|
| There are two problems with that.
|
| 1) You should not set visible from within a constructor.

Why? [ I do it almost invariably.. ]

The reason *for* doing it is bascially "Gee, I usually do this when I
make one, so let me just clump the displaying on in the constructor".
That's different than "this is the logical, encapsulated, modular place
for this operation to be".

For an example of a problem with that... what if you find that
constructing an instance of your frame object is slow? One way to fix
this would be to place needed slow construction on a low-priority
background thread, then use things after all needed objects are ready.
However, if the act of constructing an object actually shows it, then a)
it is not thread safe, and b) it can not be constructed in the
background if more than a single thing needs constructing.

Another case would be if you're going to use the instance of your
special frame, but find that you need to tweak a few things on it before
it's ready to display. If just constructing one shows it, then you're
faced with either hiding it again right away (and getting ugly flashing
on the screen) or with it showing up and then changing immediately.
Again, a visually unappealing solution.

There are more reasons, but in general it's due to forcing together
operations that logically don't belong together, even though they often
follow each other in order.

[ but note that I am also doing work in AWT,
for which Component.show was deprecated in 1.1.. ]

Yes. show() for java.awt.Component is deprecated. However,
java.awt.Window (which java.awt.Frame is derived from) overrides show()
with a version that is not deprecated. So for general components/widgets
it has been deprecated, but not for top level windows.

 

[Tony Morris]

"You should not set visible from within a constructor"

More specifically, you should not call an overridable (non-static,
non-final, non-private and a member of a non-final class) method from a
constructor.
See "Effective Java Programming", Joshua Bloch.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

| Passero wrote:
| public class Hoofdscherm extends JFrame
| > {
| > private Beheerder deBheerder;
| > private JButton btnMatrixVolledig, btnMatrixVariabelen,
btnMatrixVgl;
| >
| > public Hoofdscherm(Beheerder deBeheerder)
| > {
| ...
|
| > setVisible(true);
| > setBounds(0,0,800,600);
| > }
| >
|
| There are two problems with that.
|
| 1) You should not set visible from within a constructor.

Why? [ I do it almost invariably.. ]

The reason *for* doing it is bascially "Gee, I usually do this when I
make one, so let me just clump the displaying on in the constructor".
That's different than "this is the logical, encapsulated, modular place
for this operation to be".

For an example of a problem with that... what if you find that
constructing an instance of your frame object is slow? One way to fix
this would be to place needed slow construction on a low-priority
background thread, then use things after all needed objects are ready.
However, if the act of constructing an object actually shows it, then a)
it is not thread safe, and b) it can not be constructed in the
background if more than a single thing needs constructing.

Another case would be if you're going to use the instance of your
special frame, but find that you need to tweak a few things on it before
it's ready to display. If just constructing one shows it, then you're
faced with either hiding it again right away (and getting ugly flashing
on the screen) or with it showing up and then changing immediately.
Again, a visually unappealing solution.

There are more reasons, but in general it's due to forcing together
operations that logically don't belong together, even though they often
follow each other in order.

[ but note that I am also doing work in AWT,
for which Component.show was deprecated in 1.1.. ]

Yes. show() for java.awt.Component is deprecated. However,
java.awt.Window (which java.awt.Frame is derived from) overrides show()
with a version that is not deprecated. So for general components/widgets
it has been deprecated, but not for top level windows.