CODEWITHSUNDEEP
javaswingjframe
eXXXXXXXXXXX2
eXXXXXXXXXXX2

Reputation: 1580

setSize() doesn't work for JFrame

import javax.swing.JFrame;
import javax.swing.SwingUtilities;

class Demo
{
    JFrame jf;
    Demo()
    {
        jf=new JFrame("Demo");
        jf.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        jf.setSize(5000,5000);
        jf.setVisible(true);
        System.out.println(jf.getSize());
    }
    public static void main(String[] args)
    {
        SwingUtilities.invokeLater(new Runnable()
        {

            @Override
            public void run()
            {
                new Demo();
            }
        });
    }
}

I use jf.setSize(5000, 5000) for JFrame but after that getSize returns other size: java.awt.Dimension[width=1386,height=788] (my screen resolution is 1366x768) Can I set frame size greater than screen size? probably such behaviour is provided with some frame properties but I don't know about them.

Upvotes: 14

Views: 24523

Answers (5)

user1050755
user1050755

Reputation: 11691

Try using setPreferredSize instead of setSize. Works in my case (Ubuntu 12.04+GNOME 3).

Upvotes: 17

Tomek
Tomek

Reputation: 181

These are my observations (used 1.6, now I'm using 1.7 under XP):

You can have undecorated frame of "almost" any size -- I use screen resolution of 1280x1024 (rotated) and didn't noticed any problems with frame 1500x1500, although some frames 2000x2000 look uncompleted (but work) and frame of 4000x4000 displays its thumb in taskbar but this thumb is unactive and the frame itself doesn't appear. I think the largest possible size of undecorated JFrame is dependent on system capabilities which is dependent on the graphic hardware.

With decorated frames there is a simple story -- they can be a little larger than screen size (by few pixels in generally).

In my application with size determined during runtime (e.g. games where you set board size dynamically) I use the following approach:

1). before packing set frame location relative to null. It places the upper-left corner of JFrame in the middle of the screen (before pack the JFrame is (0,0) dimensioned)

2). set preferred sizes of my frame content (I always use single JPanel) and remember them

3). pack the frame

4). if frame sizes after pack don't match those before pack dispose the frame, remove content's JPanel, add JScrollPane with this JPanel and set the preferred sizes of JScrollPane as JPanel preferred sizes PLUS the JScrollBar fixed dimensions (i.e. a width of the vertical scrollbar and a height of the horizontal one).

5). pack again -- this guarantees only the necessary scrollbars appear (if you don't increase the JFrame sizes then both scrollbars will always appear -- there is also a need to remove the JScrollPane default border).

6). set new location of the frame by moving it left and up by the half of the corresponding size to center it.

Upvotes: 1

kleopatra
kleopatra

Reputation: 51524

Just for Friday fun (that is, nothing you should consider doing in production environment :-) - playing a bit further with @jinguy code, I noticed that the bigger-than-life size was used after minimizing the frame. Doing so programmatically let it appear as monster right from the start

    jf.setPreferredSize(new Dimension(5000,5000));
    jf.setMinimumSize(new Dimension(5000,5000));
    jf.pack();
    jf.setVisible(true);
    jf.setState(Frame.ICONIFIED);
    jf.setState(Frame.NORMAL);
    System.out.println(jf.getSize());

Upvotes: 5

Stephen C
Stephen C

Reputation: 718718

The javadoc says this:

"The method changes the geometry-related data. Therefore, the native windowing system may ignore such requests, or it may modify the requested data, so that the Window object is placed and sized in a way that corresponds closely to the desktop settings."

This covers the behavior that you are observing / complaining about.

It is not crystal clear, but one reason that Window.setSize(...) has this behaviour is that window managers (outside of Java) typically veto application attempts to do this. Presumably, that's because it is open to abuse and "not what the user wants". Anyway, it is ultimately not your application's call to override the window manager's restrictions.

Upvotes: 7

jjnguy
jjnguy

Reputation: 138864

I tried out a few combinations of calls, and the following seemed to work:

jf.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
jf.setPreferredSize(new Dimension(5000,5000));
jf.setMaximumSize(new Dimension(5000,5000));
jf.setMinimumSize(new Dimension(5000,5000));
jf.pack();
jf.setVisible(true);

It still prints out a different size, but the window appears to be far larger than it prints.

Upvotes: 3

Related Questions