Re: [lmi] MDI children order (was: wx-3.1.0 regressions)

[Vadim Zeitlin]

On Thu, 06 Nov 2014 13:40:39 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2014-10-20 22:18Z, Vadim Zeitlin wrote:
GC> > 
GC> >  In addition, while testing this, I noticed that using Ctrl-TAB to switch
GC> > between MDI windows didn't work neither when the focus was in the census
GC> > window and that this key combination was handled like a plain TAB instead.
GC> > This is fixed too now.
GC> 
GC> The keyboard mapping seems to be:
GC>   Ctrl-Tab       --> Window | Previous
GC>   Ctrl-Shift-Tab --> Window | Next
GC> but I was expecting:
GC>   Ctrl-Tab       --> Window | Next
GC>   Ctrl-Shift-Tab --> Window | Previous
GC> I'm using wx trunk as of commit 06ddf44a276524d9e154cbe6c7dd4f3d8442f912.

 It is even stranger. Keyboard mappings are correct, it's just that the
menu commands themselves work opposite to what one would expect, i.e.
"Next" actually switches to the previous MDI child, according to the order
in the "Window" menu, and "Previous" goes to the next one.

 Initially I was completely certain that this was a bug in wxWidgets. I
tried to find out when it was introduced and, to my surprise, discovered
that it was already present in 2.8 -- so that all the existing LMI versions
should be affected by it as well. Worse, I couldn't see anything wrong in
wxMSW implementation, it seemed to use MDI exactly as documented. Moreover,
I found an example from the old Windows programming bible by Charles
Petzold at ftp://charlespetzold.com/ProgWin95/CHAP18/MDIDEMO.EXE (sources
are in the same directory and you can easily compile them yourself if you
don't trust downloading and running executables from internet for some
inexplicable reason) and it exhibits exactly the same behaviour!

 After seeing this I realized that there must be some reason for this and
it was more than just a bug in wxWidgets. And I think it's actually
intentional in Windows MDI implementation that the "next" and "previous"
refer to the Z-order of the windows, not their order in the "Window" menu.
When a new window is created, it becomes top in the Z-order (and this is
how it should be, you expect a new window to appear in front of the
existing ones), so if you create 3 windows, their Z-order is "321". Now if
you press Ctrl-Tab or select "Window|Next" (they work in exactly the same
way internally), the order becomes "213" meaning that you see the previous
window in the creation order but the next one in Z-order. If you do it once
again, you get "132" and then it loops over.

 So it does have its own kind of logic, even though it's still quite
surprising. Notice that this Z-order is used for the other commands too,
e.g. "Window|Tile" would tile the windows according to it too, so that the
currently active (top) window is always the first one. And, worse, even
after spending a few hours (!) on this, I still don't see what could we
possibly do to change this. We may tweak Z-order ourselves and ensure that
it's a cyclic permutation of the window creation order, but this would mean
changing the Z-order of the existing windows when creating a new one and I
think this would be pretty surprising to the user and so undesirable.

 In short, I guess we will just have to live with this behaviour. And if
you'd like to have something more reasonable/controllable, then I think LMI
should switch to using a tab-based or (if/when it's finally integrated into
wx...) AUI-based doc/view framework, which would be preferable for MDI
anyhow nowadays (I had serious trouble finding any MDI application on my
system at all, I think MDI went out of fashion in the last century...).

 Please let me know if you see something that I'm missing, thanks,
VZ