Vertically Maximizing Window in Swing

When vertically maximizing a window on my win7 64 bit machine by dragging the top or bottom edge of the window to the top or bottom portion of the screen respectively, the application becomes unresponsive and displays a black section or some other visual distortion. Does not happen when vertically maximizing by double clicking on the edge, or regular maximizing.

Since its happening with the Java Tutorial programs (I selected a few at random, and they all do it), is this some kind of bug in Swing - or is there something I can do?

As an example the editor pane tutorial exhibits this problem. Can someone with the same OS see if this happens on their system?

It sucks because this gesture would be something that the user would do when using my app, based on the way its layed out.

I ran the editor pane tutorial via WebStart and dragged the top edge of the window to the top of the screen and a Win 7 feature took over and forced the bottom edge of the window to the bottom of the screen. The window had a dark faded edging around it when this happened which disappeared when I let go of the mouse. The same thing happened when dragging the bottom edge of the window to the bottom of the screen. The application kept on working.

I also tried it with an application on my desktop and that exhibited the same behaviour - ie it works as expected.

What version of Java are you using?

Steve Myers
Ranch Hand

Joined: Dec 08, 2012
Posts: 47

posted Jan 01, 2013 13:49:39

0

I'm running Java SE build 1.7.0_10-b18 - the latest available. I will try it on my work computer tomorrow which is a couple versions back and see what the deal is. This is only happening with Java apps, and apparently only Swing, since Eclipse doesn't exhibit the problem. Also I will look into updating my video drivers.

Steve Myers
Ranch Hand

Joined: Dec 08, 2012
Posts: 47

posted Jan 02, 2013 19:29:41

0

The same problem happens on my work computer, with J7u9 and a different video card (still Nvidia). Now I am bewildered.

There's a Windows option to turn off/on automatic maximisation which might help if you just want a workaround: Control Panel > Ease of Access Center > Make it easier to focus on tasks > Make it easier to manage windows: check/uncheck the option that says "Prevent windows from being automatically arranged when moved to the edge of the screen".

The look and feel may be relevant too. I've hit a similar problem with Nimbus whereby if you drag the bottom of a modal window up and down it crashes JVM.

Malcolm

You wait all this time for a coincidence, then two come along at once...

I'm getting something similar with the PaintPanel project I've been working on. The original panel contents remain visible, but the newly added part of the vertically maximized panel is (almost all) black.

Now, this means you've helped me find a bug in something I thought was working (oh, and thank you for that ), but maybe we can figure out what's going on and solve it.

Well, the good news is that it's not my project's fault. The bad news is that it's a bug in something else. Here's a SSCCE that shows the problem:

At run-time, after moving the frame to the middle of the screen, you see this:

Which is what you expect, of course.

If you float the mouse-pointer over the very top edge and double-click, it expands to the maximum vertical size, and you see this:

That's just what you expect too, of course.

But, if you float the mouse-pointer over the very top edge, then click and drag the top edge to the top of the screen, so that Windows automagically expands your frame to the maximum vertical size, you see this:

That is not what you expect, of course. The frame's background color expands from where it was before dragging up to the new top, but all below that has not expanded downward to the new edge. (Interestingly, if you put a panel in there, override its setBounds method, and have it print out the dimensions as you do this, it never reports the expanded height; it only ever gets passed the height of that gray interior region, so something internal to the GUI code is never hearing about that maximized height).

Seems like a bona fide bug somewhere, but I can't see how it's in that bit of Java.

Tested it as well on Windows 7 32-bit. Same problem appears there as well. Can't test it on my Fedora/Linux system, as the X-windows system doesn't seem to use the "maximize vertically when edge is dragged to boundary of screen" scheme Windows employs.

It would be interesting to add a ComponentListener to both the frame and content pane and see if they are both receiving resize events when the auto resize takes place (with consistent differences in height).
Unfortunately I don't have jdk 1.7 installed on this machine so can't try it here.

Tony Docherty wrote:It would be interesting to add a ComponentListener to both the frame and content pane and see if they are both receiving resize events when the auto resize takes place (with consistent differences in height).
Unfortunately I don't have jdk 1.7 installed on this machine so can't try it here.

I started doing something like this, but suddenly realized that the good folks at Oracle don't pay me enough to debug their code for them. Where do we report the problem?

Tony Docherty wrote:It would be interesting to add a ComponentListener to both the frame and content pane

I did that. 1.6 reports a plethora of resize events, 1.7 reports only one resize event after the mouse button is released. And the new size.height corresponds to the height from the top of the screen to the pre-maximized bottom of the frame. Calling revalidate() and repaint, even wrapped in invokeLater(...) doesn't change that. Manually resizing the width updates the height to what it should be.

Yeah, the bugs still belong to Sun. Not Oracle (though the pages do carry the Oracle logo). Makes me think of the way parents talk to each other. "My daughter came first in her class." "Your son was sent to the Principal's office."

Gosh, I hope there's a better workaround to be had (or, of course, that Oracle/Sun fixes the bug). I find that jre's seem to sprout up all over my drive like mushrooms after a hard rain. Deliberately having to keep track of a particular version for one app would be... well, not my first choice.

Near as I can tell from other experiments, this problem is universal to applications running under 1.7. That is, now that we know how to make it happen, I have been able to make it happen with pretty much every Java app I have that runs in a JFrame. I would hope that Oracle/(whomever) would see this as something they can't tolerate for very long.

Swing is in so-called 'maintenance mode', and Oracle isn't Sun. Additionally, it's fairly likely that the bug arises out of OS notification routines in native code, or even from a change in the graphics pipeline between 1.6 and 1.7.

All considered, I wouldn't expect a fix any time soon (but of course I hope I'm proved wrong!).