DocumentWindow z-order

Something strange happened to the z-order of document windows with one of the latest checkins.

My app initially opens a DocumentWindow, then, from a menu in that window, I can open other DocumentWindows.

Under some conditions, the 2nd window will be placed behind the 1st even if it has the focus, and it seems I can’t change that. As I’m typing this, the 1st window is in front of my Firefox browser.

I don’t have a C++ sample ready, I observed the effect in jucePILS and it seems consistent, but I’ll try to produce one if needed, though I’m not sure of exactly what triggers the misbehaviour.

I’ve been mucking around with the way modal components work - are any of these things modal?

If you can show me something I can reproduce, I’d like to try to figure out what’s going wrong…

I just found out what triggers the behaviour.

It happens when I open the 2nd window from a submenu of a menu in the menu bar of the 1st window. The problem disappears when I flatten the menu structure (which I don’t want to do).

(The menu is similar to File->Recent files… if I put the individual files directly under “File”, there is no problem.)

So, I assume it has something to do with menus being implemented by modal components, and some test against this not working properly with multi-level menus.

I think it’s MSW specific, haven’t seen it on the Mac.

I’ll try to produce a C++ sample sunday, I’m at work and the sample code is at home.

I’m just debugging this at the moment, and it’s baffling.

It’s nothing to do with modality, it’s because the menus are always-on-top windows… If you show a single menu, everything’s fine, but as soon as you open a sub-menu, for some bizarre reason, the document window instantly becomes “always on top”. But I’ve run tests and it’s definitely not my code that’s changing it! I think it must be some side effect of changing z-order when there are 2 topmost windows active, but am struggling to find the exact reason…

Ok, I think I’ve cracked it - try this change to the win32 code:

    void toBehind (ComponentPeer* other)
        Win32ComponentPeer* const otherPeer = dynamic_cast <Win32ComponentPeer*> (other);

        jassert (otherPeer != 0); // wrong type of window?

        if (otherPeer != 0 
             && otherPeer->getComponent()->isAlwaysOnTop() == getComponent()->isAlwaysOnTop())

I think that if you try to put a topmost window behind a normal one, it promotes the normal one unexpectedly. Very annoying, but I think this should sort it out.

Thanks, this fixes it. (Hope to see it the trunk soon.)