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.
Also, is there any way to get the z-order of the desktop windows?
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.
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?
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!