I stumbled across an interesting phenomenon today. I was under the impression that relations were always evaluated from top to bottom, in their entirety. A simple example seems to show that this is not always true:
A = 0
IF A == 0 B = 1 ENDIF
With these statements, both 'A' and 'B' will remain locked, as expected.
Now add one more statement to the bottom:
A = 0 IF A == 0 B = 1 ENDIF A = 1
Suddenly 'B' becomes unlocked and changeable.
What was even more surprising was that entering a different value for 'B' and then running "Verify Relations" one time did not change 'B' back to "1.0000". It took a second "Verify Relations" pass to get it to snap back to the intended value.
If the relations are being fully processed each time "Verify Relations" is pressed (or the model is regenerated), it should never be possible to have 'B' left at anything other than "1.0000". Frankly, 'B' should never unlock either since 'A' should always be "0" every time the relations are evaluated.
Just to make sure I wasn't going crazy, I went back and tested this in Wildfire 5 and the behavior was the same. What do you think? Is this the correct behavior or is something wacky going on here? Should it take two regenerations (or two separate "Verify Relations" commands) to get 'B' back to "1.0000"?
I struggle to think of a reason for wanting this behavior. Out of sequence evaluation requires a lot of effort and I don't see why it would be applied to relations. I think it's a bug that replaced another bug.
They need to run a search against the coders who worked on this and their resumes. Look closely at any code where someone has significant background in Haskell or Forth.
(I'm kidding, just kidding. But if an hour long YouTube tutorial on what a Monad is is still unclear I don't understand how anyone learns it.)