Z-order to front of component?

There is a method to put a component behind another one:

void Component::toBehind (Component *other)

Why isn’t there a method to put it in front of?

(I use toBehind two times as a workaround but that’s probably not the best way).

Umm … there is a Component::toFront() method?

1 Like

This is not Component::inFront (juce::Component *other).
Notice that there is toBack() and toBehind (juce::Component*).
Notice that there is toFront() but NOT (…).

I assume it’s because you can just use toBehind(). Putting A behind B the same as putting B in front a A is it not? Why do you have to call toBehind() twice?

Object A is index 3.
Object C is index 4.
Object B is index 9.

I have pointers to A and B. How to put B between A and C (i.e. in front of A)?

A behind B? Thus A is front of C. Wrong. B behind A, then A behind B. Good.

So you have no access at all to object C? Sounds like that might be part of the problem :man_shrugging:

The z-order is simply specifying the order of the child components from back to front.
It is possible by combining several calls to achieve any order you want.

Basically you use the component as index where to move the called component to, see the sources:

To implement a toInFrontOf() you would need access to the actual indices, so you could place the item after the selected component instead of before.

All in all I agree with the OP that this is relatively inconvenient, even though workarounds exist, which require some quirks and yield hard to read code.

1 Like

Unless the juce team has good reason not to, OP is correct in that this should be added to the API for consistency.


A more generic alternative would be to expose the reorderChildInternal. You can figure out the index of each component with the public API, so you could move any component to where you want it to be…

Note that If you read old posts about Z-order in this forum, it seems that Jules (JUCE) preferences were more in favor of the behind/front mechanism that index based approach.

1 Like

I also agree with @nicolasdanet, a toInFront() method would be very useful.

It would also be very useful to have the value of z-order’s persist.

parent.addChildComponent (component1, 0);
parent.addChildComponent (component2, 100);
parent.addChildComponent (component3, 50);

Currently, component3 will be placed last in the z-order even though the explicit z-order that was requested was less than that of component2 - I’d love to see it that I could call getZOrder on a component and it would return the value I passed in to the parent’s addChildComponent. A setZOrder would also be useful to be able to change the order later on.

1 Like

JUCE doesn’t implement a Z-order.
If they would add a property for that, they would have to sort the components list each time (sure, it could be cached).
The way it is done it’s simply a list you can manipulate.

It has a very basic concept of a z-order in that you can specify which components should appear in-front of which of their siblings. Don’t get me started on the need to be able to put components in-front of others that aren’t their siblings - I’ve run into that problem countless times.

A comprehensive z-order implementation would be extremely useful IME.


+1 for this to be implemented.
I just hit a case where it would be very helpful to have such a toInFrontOf() (or simply toFrontOf, toAhead).