toBehind might have bug on mac

MacOSX and iOS
1

I think if you have three components on the desktop A B C (in that z-order) and then you call C->toBehind(A) nothing happens because C is already behind A.

But, if you go:

C->toFront(false);
C->toBehind(A);

then you get the z-order A C B which is what I am trying to achieve.

2

Also, is there any way to get the z-order of the desktop windows?

3

Hmm. Yes. That’s annoying. As far as I know there’s no other mac call that will do the job. Drat. I’ll have to do some research on this one. And I don’t know of any way to find the z-order either.

Something I’ve had on my to-do-list for a long time is to add a proper mechanism for specifying z-order of windows, using window groups on the mac, and hacking it on win32, which will hopefully avoid having to manually force things like this.

4

Is there a reason popupmenu does this after finishing?

if (deletionChecker2 != 0 && ! deletionChecker2->hasBeenDeleted())
prevTopLevel->toFront (true);

shouldn’t it already be in the front once the menu is deleted?

5

There was definitely a situation where it needed to do that. Can’t exactly remember what it was though - that’s been in there a long time!