Frame Z-order in Java?
I must be missing something obvious. Is there a method anywhere in the AWT (preferably in Java 1.4 but maybe 1.5) that allows me to determine the z-order, relative or absolute, of free-standing windows such as frames and dialogs? Specifically I need to know which of several dozen frames is on top among that group. To make this trickier:
- There may be other frames and dialogs that do not count. For instance, if the preferences dialog is really on top, I still need to know which of my application’s document windows is on top among the document windows.
- I need to know this even when the application is in the background, so that the top window may not be active.
Surely there’s a function for this somewhere? If not, it’s a pretty glaring hole. Do I really have to write code to watch each and every operation that can move a frame to the front, and track the front window manually?
July 13th, 2006 at 2:06 PM
It appears that you are correct about there not being AWT methods for discovering the z-order.
But is it that big a deal to write a single WindowListener (or WindowStateListener or WindowFocusListener) that keeps track of the last one that was activated/focused and add it to the frames/windows/dialogs that you care about? This does not seem like a huge amount of code to me, but your mileage may vary.
July 13th, 2006 at 3:18 PM
The JavaDoc warns that bringing a window to the front does not necessarily focus or activate it. Sending it to the back does not necessarily defocus or deactivate it. Furthermore a window may still be in the front of the application, but unactivated if another application is in front.
July 13th, 2006 at 5:14 PM
I wonder why Sun thinks that the javadoc for Window.toFront() and Window.toBack() is the only place to document this stuff (at least as far as I can find). I did not see this in the tutorial or in the javadoc for the various window listeners or events.
Anyway, the scenario I was picturing did not include using toFront() or toBack(). If you click on a frame with a mouse or create and show a new frame, it will necessarily become the active one, no? Same for ALT-Tab type of selection?
As for another application being in front, as long as you kept track of the last front window of your app, it doesn’t matter. As before, this is without considering toFront() or toBack().
The keeping track part is harder than I thought I first though. You need an ordered activation list. If you close a frame, it does not necessarily activate another of your application frames.
Overall, I guess your point is well taken. Having an API for this would be much nicer.
July 14th, 2006 at 11:34 AM
*several* *dozen* frames ??? sounds like a really cool app…..
July 15th, 2006 at 4:57 AM
Consider registering as PropertyChangeListener with the KeyboardFocusManager in order to intercept events indicating a focus move between different windows:
KeyboardFocusManager.getCurrentKeyboardFocusManager().addPropertyChangeListener(new PropertyChangeListener() {
public void propertyChange(PropertyChangeEvent e) {
if (e.getPropertyName().equals(”activeWindow”)) {
//do something
} else if (e.getPropertyName().equals(”focusedWindow”)) {
//do something
}
}
});
July 16th, 2006 at 7:08 AM
The application in question is Amateur. It doesn’t really need several dozen frames most of the time, but I’m a firm believer in not putting arbitrary limits on applications. If a user wants to open a few dozen movies at once, who am I to tell them they can’t?
July 17th, 2006 at 12:30 PM
Looks like there is some new functionality in 1.5:
java.awt.Container.[sg]etComponentZOrder()
http://java.sun.com/developer/JDCTechTips/2005/tt0118.html
July 18th, 2006 at 5:46 AM
I looked at that but it only applies to components in frames, not to freestanding windows.
May 20th, 2007 at 12:29 PM
It would be great to get the Frame z-order. This would help in handling “floating” paltetts that use the setAlwaysOnTop method. Is there anything new in 1.6?