- Home /
UI hierarchy: How to predict the order in which Start() is called?
Hello Unity Community,
Given a hierarchy of UI elements, is there a way to change or predict the order in which Start()
is called? For example: One of my Scenes has the following hierarchy:
Scene:
|- Canvas
|- Panel Player 1
|- Some UI elements
|- Some UI elements
|- Panel Player 2
|- Some UI elements
|- Some UI elements
|- Panel Player 3
|- Some UI elements
|- Some UI elements
|- Panel Player 4
|- Some UI elements
|- Some UI elements
Note: "Panel Player 1-4" are four instances of a prefab.
Now, when stepping through the code, the order in which the various Start()
methods are executed is:
Player Panel 2
Player Panel 4
Player Panel 3
Canvas
Player Panel 1
Kinda arbitrary... isn't it? Now I'm curious what causes that order and how to change it. Is there a way to influence the order in which the Start()
methods are called? Or is this a bug in Unity (5.4.1.f1)?
One thing that's remarkable is that it's always the same order. Also Start()
and Awake()
of both, the Canvas and the 'Panel Player 1-4', are empty (i.e. they ain't call each other). However, canvas and panels do have references assigned to each other in Unitys inspector view.
Please let me know if you have any explanation about what causes that weird execution order and how to fix it. Thank you!
Answer by doublemax · Oct 11, 2016 at 11:58 AM
Thank you very much! That link explains a lot. The arbitrary script execution is an... interesting... concept. Funny enough, after specifying the script execution order, the Start()
methods of the four player panels are now called twice. Need to figure out why somehow, but anyway, thank you!
"arbitrary" probably means: In the physical order they are found in the filesystem.
I think it's worth saying that if the order of execution makes a difference, there's probably a better way of doing things.
If the set-up methods of UI elements (or any other GameObjects, really) are inter-dependent in some way, I$$anonymous$$O it's better to find a way of having them set each other up, or create a manager object of some sort that sets them up (in their dependent aspects, at least), rather than relying on Start() functions.