This is a stripped down version to produce the bug. Assume that I do use something from Unit2.
Edit:
Notice that it works as expected if you change the order in the lpr file.
Usually we do not rely on the order of initialization, and we can do the same here by using a function, for instance, instead of SensorLocMap.
The rule is that unit initialization order is defined using left-to-right depth first search manner of the uses clause, following the parser movement. e.g.:
- suppose we have program A, unit B and unit C
- A uses B,C
- B uses C
- C uses B
In above case, the parser movement is as follows:
- Parse A
- Encounter B in A's uses clause, parse B
- Encounter C in B's uses clause, parse C
- Encounter B in C's uses clause, do nothing (B is being parsed)
- End of C parsing, put C to unit initialization order
- End of B parsing, put B to unit initialization order
- Encounter C in A's uses clause, do nothing (C is already parsed)
- End of A parsing, parsing done
As you can see, the final order is C then B. Now modify above flow with A uses C,B instead of B,C and try to follow the parser movement. See the order of "put X to unit initialization order", that's what you finally get. The documentation actually mentions this, albeit not as comprehensive as this example (probably too verbose).
Attached is a very simple example that demonstrates this behavior. Each unit's initialization section will call WriteLn, the output is the final initialization order.