Action cells in Visio react differently from the others and you can use this behaviour to your advantage when building complex shapes.
Cell dependencies
Cells in Visio are chained together through a series of precedent and dependent cells. To create a dependency you just write the name of another cell into a target one and hey presto you've got a working chain. For example, here's four User cells:
In the above screenshot you can see that User.Bob has one precedent (User.Jane) and therefore, in turn, User.Jane has one dependent (User.Bob).
[Note, you don’t need to know about this if you’re not writing code, but a little understanding of what’s going on in the background can also help you understand the ShapeSheet a little better.]
Cells have two events that support the chain of updates that have to occur in order to keep all cells in sync and that’s FormulaChanged and CellChanged.
A FormulaChanged event fires when the formula expression is written to, either via the ShapeSheet or in code, and this is a relatively infrequent event.
The CellChanged event, on the other hand, is fired every time the value of the cell is updated. When a CellChanged event occurs, and the value changes, all dependent cells are also triggered, causing re-evaluation. The process is then repeated all the way down the dependent chain until either a leaf cell is reached (ie one with no further dependent cells) or, no value change occurs.
So let’s run the Event Monitor and change User.Jane from 8 to 5:
As you can see, the first thing that happens is the FormulaChanged event is fired as the formula string is set to “=5”. This creates a follow on CellChanged event in User.Jane which triggers cell evaluation in the dependent cell, User.Bob.
As the value of User.Bob has changed any cells that depend on it also get triggered and so, in this case, a CellChanged event also fired for User.BobAndMary. Finally, since User.BobAndMary has no further dependent cells, this is where the sequence completes.
So this is basically how cells work in Visio. There are a few things that change evaluation, for example, GETREF and GETVAL prevent cell re-evaluation when their containing references changes and DEPENDSON is used to create one or more dependencies that otherwise do not naturally exist in a hosting formula, but, by and large, changes in one cell propagate down the chain through all cells in all sections.
No auto-trigger in Actions
The one caveat to this (as far as I’m aware) is the Actions section and, in particular, the Actions column of the Actions section. Unlike other cells, Action cells are not triggered when precedent cell values change, but only when specifically invoked via the context menu. But, it turns out, there are other ShapeSheet ways of triggering these cells.
Knowing that these cells have different behaviour means that, potentially, they can be used in different ways.
For example, if you think about a shape that supports multiple types, switching from one type to another might involve changing a number of different Shape Data or User cells such as size and colour, particularly if the options are not mutually exclusive. Normally you might add a number of chained SETFs and repeat this Action row for all of your combinations:
An alternative might be to add a fourth row (without the Menu cell populated so that it doesn’t show up in the UI) and then use EVALCELL to trigger the new ‘work’ cell:
This is useful in shortening the first three formulas and, if you have a larger number of SETFs then its usefulness increases. Another scenario is where you might want to invoke the same functionality from more than one place. For example, imagine a reset function that you want to invoke from the EventDrop cell and also from a context menu item.
I’m sure there are other uses which I’m yet to discover, but the real insight here is that there’s a place to put function style formulas that you don’t want firing off except when specifically told to do so.
You might be thinking, why not just put the SETF formula in a User cell? One reason not to do this is that it might get fired when you’re not expecting it. For example, if you have the SETF in a User cell in a master and then a new User cell row is added to the instance shape, the action of adding this new row will, *temporarily, make all of the User rows local firing the trigger on each cell along with your SETF. Using a spare Action row isolates it from this auto-triggering behaviour.
[* I say temporarily, because Visio will tidy things up on document save and re-implement inheritance where row values match.]
