Order of value evaluation of controls.

[Albert]

Hello All,

If ControlSource of textbox B = some-expression(A) and ControlSource of
textbox C = another-expression(B). Does Access know that it have to evaluate
B before C ? Any guarantee ?

TIA,
Albert

 

[Marshall Barton]

If ControlSource of textbox B = some-expression(A) and ControlSource of
textbox C = another-expression(B). Does Access know that it have to evaluate
B before C ? Any guarantee ?

I can't guarentee anything, but I've never seen that fail.
After all, keeping a calculation dependency tree is a well
understood requirement. E.g. spreadsheet programs have done
this for ages.

The difficulty that does come up from time to time is when
someone tries to throw an event procedure into the mix.
Control expression evaluation runs at a lower priority than
execution of events, so this kind of thing is not reliable:

textbox B: =some-expression(A)
textbox C: assigned a value based on textbox B in an event
textbox D: =another-expression(C)

 

[Albert]

Thanks for your information. Very interesting to know that "Control
expression evaluation runs at a lower priority than execution of events".
May I ask you , Where can you find this information ?

Regards,
Albert

 

[Marshall Barton]

Thanks for your information. Very interesting to know that "Control
expression evaluation runs at a lower priority than execution of events".
May I ask you , Where can you find this information ?

I don't know if/where this kind of thing is written. I
deduced it while analyzing a problem I was having.

Another obvious example of Access' pseudo multi-threading is
in painting the screen where updating a control on a form in
a VBA loop (e.g. a progress thingy) only displays the last
value after the loop completes. In this situation, Repaint
can be used to force the screen update, but calculations can
be overwhelmingly complex and, AFAIK, there is no guaranteed
way to sync code calculations and control expression
calculations.