There appears to be no way to know what a maximized window's
dimensions will/should be under Windows 95/NT 4.0. This is
because there is no way to discover/account-for the presence/
absence/size/location of the Windows Taskbar (and any other
registered taskbars - such as office). This makes it possible to
easily create frames which get at least partially obscured by the
taskbars and almost impossible to set frames so that they fill
the screen area up to the taskbars.

Toolkit.getScreenSize() always reports the size of the entire 
screen (which it probably should).

The screen is somewhat like a window  customer  in that it needs to
have Insets.


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




Nearly all modern operating systems have floating control bars,
which mostly are set to always on top mode. Under windows we have
the taskbar and native windows programs are able to take care about
that. That means that native windows programs have the possibility
to adjust there size on the available screen size.
Now we need this in java, too!
Would like the following method in the Toolkit class:

public static Shape getUsableScreenSize()

This method should return the bounds of the available client area,
on platforms where this is not possible or too difficult to compute
it just should return the screen bounds.

I don't see any other solution to the following problem:

How limit the size of dialog boxs to the visible screen size?

On frames a workaround could be to make them full screen, but
on dialog boxs?

Thanks
   Patrick
(Review ID: 84038)
======================================================================

This is very noticable under Windows with the taskbar along the top of
the screen.  Java Frames almost always appear with their title bar
obscured by the Task bar.
  xxxxx@xxxxx   2000-01-04

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

Seems reasonable.

1.4 adds java.awt.Toolkit#getScreenInsets() to address this concern.

  xxxxx@xxxxx   2003-01-16

I am suffering from this problem, too. For
instance, if you have a large JFrame that is too
large to fit within the screen, calling pack() will
shrink it down to fit the screen. However, when
displayed, it will be partially hidden by the
Windows taskbar because Java did not take it into
account when resizing.
If I remember correctly from my Win32 programming
days, getting the size of the desktop via the
Windows API will actually return the size of
the *visible* desktop (= the actual desktop
minus the dimensions of the taskbar). This prevents
normal Windows applications from sizing themselves
in such a way that puts them underneath the taskbar.
So, I think the best solution to this problem is
to modify Toolkit.getScreenSize() so that it
returns the visible desktop, which is what I
believe the regular Win32 function for getting
the desktop size will return. (The Windows VM
must be doing it in some non-standard way.)

There should be two methods. One should return the full 
screen size, and the other should return the usable screen 
size. That would make them platform independent. The 
comments for the full screen size method should discourage 
its use in favor of the usable screen size. This is why the 
popup menu (and pull down menus) get obscured by the task bar. 
I would prefer it if the current method returns the usable screen 
size, but that's not as important, as long as there are two.

This is also a problem with pop-up menus and comboBox's. If you place them at 
the bottom of a frame, and have the Windows Task bar at the bottom (and 
let's face it, most users don't even know it can be moved !-) the combo will
pop-up behind the task bar. 
The javax.swing.plaf.*ComboPopUp.computeRectangleBounds(int,int,int,int)
will need to use the enhancement.
Uncle Bill seems to have a method in his package
Rectangle com.ms.wfc.Screen.getWorkingArea()
So c'mon guys, it shouldn't be hard for Sun to sort something out in 3 years !

Related bug: 4245587

Why this is still in non-public release for nearly 3 years 
even it is fixed and 1.3 is available? Have I missed 
something?

Here's the workaround we use:
Create a sub-class of the JDialog and override the "show" 
method such that:
(We use 40, which would account for a "double" taskbar--
someone that has made their taskbar have two rows of icons).

   public void show()
   {
      
      // Account for the taskbar at the bottom and reduce 
the size by 40
      Dimension dialogSize = this.getPreferredSize();
      Dimension screenSize = Toolkit.getDefaultToolkit
().getScreenSize();

      // Is the popup going past the screen height? If so 
adjust
      if ( dialogSize.height >= screenSize.height )
      {
        // 40 below for toolbar at bottom        
        setSize((int)dialogSize.getWidth(), (int)
(screenSize.getHeight() - 40));
      }    
      
      super.show();
 
   }

Slight change to my earlier workaround:
   public void show()
   {
      
      // Account for the taskbar at the bottom and reduce 
the size by 40
      Dimension dialogSize = this.getPreferredSize();
      Dimension usableScreenSize = Toolkit.getDefaultToolkit
().getScreenSize();
      usableScreenSize.setSize(usableScreenSize.width, 
usableScreenSize.height - 40);

      // Is the dialog going past the screen height? If so 
adjust
      if ( dialogSize.height >= usableScreenSize.height )
      {
        // 40 below for toolbar at bottom        
        setSize((int)dialogSize.getWidth(), (int)
(usableScreenSize.getHeight()));
      }    
      
      super.show();
 
   }

I hope the pre-built dialogs of Swing, like displayed as a 
result of calling JColorChooser.showDialog(), will use the 
new method too...

So, what is now the solution?

why is this bug closed ?

we are still seeing this in 1.4.1.  What is the fix?

I think the issue is around LAFs that use undecorated frames.
If you use the WinLAF it works fine (on 1.4.2_02) but if you 
use metal it doesn't.

Until this is addressed the following snipped seems to solve 
the problem:

public static class MyFrame extends JFrame
    {
        public synchronized void setExtendedState(int state)
        {
            Rectangle maxBounds =
                GraphicsEnvironment
                    .getLocalGraphicsEnvironment()
                        .getMaximumWindowBounds();

            setMaximizedBounds(maxBounds);
            super.setExtendedState(state);
        }
    }

HTH