It appears as if JDK 1.1.3 has trouble calculating
the correct Insets for a Frame if that Frame
contains a MenuBar. This makes it working with
LayoutManagers particularly troublesome.

The following app displays a Frame containing three
buttons. The Insets for the Frame are reported as
[t=23,l=4,b=4,r=4] which effectively results in a
4-pixel border around the window.


import java.awt.*;

public class TestApp1 extends Frame {

  public TestApp1()
  {
    setLayout(new FlowLayout());

    add(new Button("One"));
    add(new Button("Two"));
    add(new Button("Three"));

    pack();
    System.out.println(this.getInsets());
  }

  public static void main(String[] args)
  {
    TestApp1 app = new TestApp1();
    app.show();
  }
}

The following application adds a simple MenuBar to
the application above. When the MenuBar is added,
the Insets for the Frame are reported as [42,4,-15,4]
which causes the LayoutManager to position the
buttons so that they are not completely visible!


import java.awt.*;
import java.awt.event.*;

public class TestApp2 extends Frame {

  public TestApp2()
  {
    setLayout(new FlowLayout());

    MenuBar mbar = new MenuBar();
    Menu file = new Menu("File");
    mbar.add(file);

    MenuItem quit = new MenuItem("Quit", new MenuShortcut(KeyEvent.VK_Q));
    quit.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent e) { System.exit(0);}
    });
    file.add(quit);
    
    setMenuBar(mbar);

    add(new Button("One"));
    add(new Button("Two"));
    add(new Button("Three"));

    pack();
    System.out.println(this.getInsets());
  }

  public static void main(String[] args)
  {
    TestApp2 app = new TestApp2();
    app.show();
  }
}


One might also argue that the default Insets for
a Frame should provide a 0 pixel border around
the edge of the frame. This would allow clients
to draw across the entire Frame without having to
jump through any hoops...

======================================================================

Add the following method to any class which
inherits from Frame. Of course, this method is
platform specific and applies only to Windows
95/NT.

public Insets getInsets()
{
    return new Insets(42,4,4,4);
}

or better yet

public Insets getInsets()
{
    return new Insets(38,0,0,0);
}
======================================================================

Definitely a problem for a frame with a menubar.

  xxxxx@xxxxx   1997-11-17

I should also add that the same probelm applies 
to a Frame started by an applet. The Frame is
then too small by te height of the "Untrusted
applet window" box at the bottom of the Frame.

This bug is causing me severe problems. I have a
(100% pure java certified) application in which
my user can build displays and specify the client
area size. I create a canvas of that size and 
place it in a Frame, and pack the Frame. The 
user then sees a client area smaller than that
requested and gets *very* confused.

The "nice" thing about this is, that
the user finally is not seeing the "Applet Window
Warning", so your Frames look very serious!
:-(

I just want to add a 'me too' for the related problem
of the untrusted applet warning that eats into a
Frame.  I noticed, though, that this problem doesn't
seem to affect Swing JOptionPanes, but I don't
know if that's coincidence or not.

Another work around which works regardless of 
whether a MenuBar is present or not, and is 
platform independant is to include the following
in any class that extends Frame:
public void pack() {
  super.pack();
  Insets insets = getInsets();
  if ( insets.bottom < 0 ) {
    Dimension size = getSize();
    size.height += (insets.left - insets.bottom);
    setSize(size);
  }
}

Agree, a-greee!
What I think we need is to get the pluggable look and feel happening, including
the following:
 - a "standard" set of widgets/layout styles. Just like developing
for macintosh, there is a standard you can keep to, Java should provide a
similar standard.
 - a "standard" set of menus/icons, etc.
 - guidelines (documentation) for writing to the standard.
 - TO THE PIXEL layout control of components which doesn't seem to be the case
currently (ie. Win32 Frames - and Windows don't allow menu-bars, I believe).

Yeah, Yeah.... please fix this bug, it's caused me alot of headaches too ! I
think it's similar/same to Bug 4072855, which I had just posted a comment to.
However, seems that in one instance of my fruitless attempts to analyse this
bug fully, I discovered that Netscape Communicator 4.03 with the AWT1.1 PR2
patch seems to layout it correctly....
Somebody fix this quick.... 

This must be the bug that causes all my components
to shift up (with some of them getting caught
under the title bar) when running my application
on a Windows NT machine (on my Mac development
machine everything looks just fine). Please get
this thing fixed as fast as possible (with the 0,0
coordinate UNDER the window title bar!)

Possible workaround;
disclaimer: I tried the code under solaris, and 
jdk1.1.4 and can't reproduce it. 
But I remember a similar problem I had with earlier
versions. If memory serves, I dealt with it by
adding a Panel to the frame, and then adding
everything to the PANEL, instead of to the frame
directly. Seemed to work at the time.

Would someone in-the-know be prepared to give me
an idea when (if ?) JDK116 will ship. I have users
screaming for this fix and all I can say is 
"JDK116". They say, "When's that then ?" and I say
"don't know".
Seriously, please help me with this.
Thanks
Rob

Here's a really simple fix that should work on all platforms...
pack();
setMenuBar(theMenuBar);
pack();
Packing before setting the menubar sets the width of the window, which means
that the system can now accurately determine the height of the menubar (before
it wasn't sure how many rows it would be, and so used the maximum). Somehow
this also fixes the bottom insets. The problem is, once the menubar is added
the window is now a little bit too small. The second pack fixes that.
Dan List
Fontanus, Inc.

Dan, you're a genius.

I'm using Windows NT 4 and JDK 1.1.5. CarlSayres's work-around works perfectly,
but Dan's generate a "FATAL ERROR" in a native class of the AWT. I
also tried theferret's work-around, but it's not changing anything. I
downloaded the JDK1.2Beta2, but this problem seems not to be corrected. So,
don't even think to use JDK1.1.6!! I hope Sun will take this problem a little
bit more seriously, because it's really annoying!!

FWIW, this is the workaround I came up with
for my class that extends Frame.
  public Dimension getPreferredSize () {
    Dimension d=new Dimension(super.getPreferredSize()); // get what is
normally returned
    MenuBar mb=getMenuBar();
    if (mb != null) {
      Font f=mb.getFont();
      d.height+=(f.getSize()+8);  // I counted 8 spacing pixels in a Win95 AWT
MenuBar.
    }                             // There is probably a better value to use.
    return d;
  }
If the MenuBar comes in different sizes, it might
provide more portability than overriding getInsets()
with fixed values.  Maybe.  I'm still learning.

It appears that Dan List has the right idea.
In API 1.0.2, I use resize(640, 480) in the Frame Constructor to set an
arbitrary width (the max screen size for my applet), then add the MenuBar, add
components, pack() and show(). It works. The Frame shrinks to the correct size.
This is (was) a very frustrating bug. Was an "official" workaround
ever posted? (I still have use for the old 1.0.2)
Greg Durniak

Oh yeah this is fixed alright! On my Win/95 system
running with JDK 1.2 (excuse me, Java 2) the value of Insets.top goes from 28
(before adding the menuBar) to 75 after adding the MenuBar. That increase is
about twice as much as it should be! I'm tempted do make a new bug report on
this...

To make matters even more confusing, when the same program is run on Microsofts
JVM, Insets.top doesn't change at all! I wonder if that has something to do
with the origin of this bug?