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:

  1. 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.
  2. 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?

13 Responses to “Frame Z-order in Java?”

  1. David Browne Says:

    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.

  2. Elliotte Rusty Harold Says:

    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.

  3. David Browne Says:

    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.

  4. dvholten Says:

    *several* *dozen* frames ??? sounds like a really cool app…..

  5. Michael Rudolf Says:

    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

  6. Elliotte Rusty Harold Says:

    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?

  7. Ralph M. Prescott Says:

    Looks like there is some new functionality in 1.5:

  8. Elliotte Rusty Harold Says:

    I looked at that but it only applies to components in frames, not to freestanding windows.

  9. cchiro Says:

    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?

  10. John Says:

    It is two years since the original post and yes, it STILL would be nice to have such a utility. It appears getComponentZOrder works only for JInternalFrames (because you can’t attach JFrames to a Container which serves as the z-order reference point). I know because I tried to do just that. I have an HTML cradling an applet which itself launches several quarter-screen-or-so JFrames, and I’d like to know the z-order of the HTML as well as all the JFrames. I gave the applet a Container and wrote a function which would add to it any JFrame received as an argument. It crashed. As this ought to have been fully foreseeable, I wonder now why it even compiled.

  11. John Says:

    ‘Scuse me, three years since the original post. Since I’m back, I might point out that I tried the PropertyChangeListener business or as close as made no difference, and it did indeed make no difference. Nice idea, though.

  12. doron ben Says:

    for jdialog or jframe with the same father you can add mouse Listener and than in it call
    Window [] winArr=Window.getWindows();
    for (int i = 0; i < winArr.length; i++) {
    it will bring all the windows with this father so you can sort them by name set the ones you want to the front by
    it will take them to the front

  13. nenopera Says:

    Use the layered pane

    See this:

Leave a Reply