Program not repainting upon JFrame height maximizing

Question

You can resize JFrame with mouse dragging in several ways:

1. You can resize it\'s height (top/bottom edge)
2. You can resize it\'s width (left/right edge)<

Answer 1

It appears to be a bug in the Windows implementation of Java. (I am also using Windows 7 and JDK7.)

When Windows decides to change the height of the window, a COMPONENT_MOVED event is received by Window, but no COMPONENT_RESIZED event is received.

Inside the Windows class, the non-public method dispatchEventImpl() will respond to COMPONENT_RESIZED events by calling invalidate() and validate(), but it will ignore COMPONENT_MOVED events.

Here is a brute-force method of making the window re-validate itself after such an event. This may occasionally make the window re-validate in other situations, but not very often since the Window class itself is doing re-validation after every COMPONENT_RESIZED event, and the reported bug only happens when the window is being actively resized by the user.

    masterWindow.addComponentListener(new ComponentAdapter() {
      private int oldWidth = 0;
      private int oldHeight = 0;

      @Override
      public void componentResized(ComponentEvent e) {
        oldWidth = masterWindow.getWidth();
        oldHeight = masterWindow.getHeight();
      }

      @Override
      public void componentMoved(ComponentEvent e) {
          if (masterWindow.getWidth() != oldWidth || masterWindow.getHeight() != oldHeight) {
            masterWindow.invalidate();
            masterWindow.validate();
          }
          oldWidth = masterWindow.getWidth();
          oldHeight = masterWindow.getHeight();
      }
    });

Answer 2

BTW: Action 5 can also be invoked by double-clicking on the top/bottom corner of a window (in Windows 8 at least).

@Enwired: Your solution works only when the window is actually moved during the maximize. But it does not work, when the window is already at y=0, when invoking the vertical maximize. (I use a little tool called AltDrag which snaps windows to the borders of the screen, which makes this case a lot more likely. But a new window which wasn't moved or repositioned initially might have the same problem.)

I noticed, that when a window is vertically maximized paint() is called once on the window.

So a solution for the maximize action would be to override paint() and do this:

@Override
public void paint(Graphics g)
{
    checkResizeWindow(this);
    super.paint(g);
}

public static void checkResizeWindow(Window window)
{
    if (!window.isShowing())
    {
        return;
    }
    Component[] components = window.getComponents();
    if (components.length == 0)
    {
        return;
    }
    Component comp = components[0];
    Insets insets = window.getInsets();
    Dimension innerSize = window.getSize();
    innerSize.width -= insets.left + insets.right;
    innerSize.height -= insets.top + insets.bottom;
    if (!innerSize.equals(comp.getSize()))
    {
        window.invalidate();
        window.validate();
    }
}

The calculation i use is to determine if the window actually needs revalidation, by checking the the innerSize against the first child component's size (which usually is a single Panel filling out the whole innerSize).

But, the same original problem still remains for the restore action. We would have to find an event which is called in that case and also call checkResizeWindow() at that point.

I was also thinking about...

• using other events like MouseMotion or Focus, but they occur only later and some might even occur very often which could cause problems with our checkResizeWindow() method when being invoked too fast repeatedly.
• using a recurring polling check calling checkResizeWindow() on every window, but polling is a bad concept in general and has it's own downsides.