DocumentWindow z-order


#1

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.


#2

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…


#3

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.


#4

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…


#5

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.


#6

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