I've seen a few claims here recently that if you have a triggered auto-enter calc field, that you must set the trigger field to a different value in order to trigger a recalculation. Some people recommend using a Timestamp for the Trigger field this reason (Example)
In my testing this is never true, and I'm curious if anyone has a counterexample.
The only time I can get the calc field to fail to update is if I don't actually change the trigger field, e.g. if I simply Tab into the trigger field then Tab out again.
But any other action, such as typing "23" when the field already contains "23" and then Tabbing out, or running a script step such as:
My experience has always been that the trigger field needs to be modified, but that modifying the the value to set it to its same original value still will get the job done to nudge the auto-enter calc to re-evaluate.
That said, in practice, I often to actually set the trigger field to a different value. In the past this was out of fear that some day what I had observed would change between version releases, and later just because I found it handy to store the current host timestamp in the trigger field.
The timestamp has another advantage in providing an indication of last triggered change. In this way, you are able to confirm that the trigger has actually been set.
As @xochi example shows, this is true/ However the typical use for a LET trigger is outside of the scope of the core field's data entry. The trigger only comes to play IF you want to force a calculation to execute (most often, replacing an unstored calc with a user/code initiated re-calc). The auto-enter for the field would execute on direct entry, regardless of whether the trigger field changes or not.
In this way, you are able to confirm that the trigger has actually been set.