Skip to content
  • Home
  • Work
  • About
  • Blog
  • Contact

Action cell execution in Visio

John Goldsmith's profile image

John Goldsmith

03 March 2018
  • ShapeSheet

ActionCellExecutionInVisio

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:

VisioPrecedentsAndDependents

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:

VisioEventMonitor

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:

VisioActionsA

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:

VisioActionsB

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.]

Microsoft MVP Logo

John has been a Microsoft MVP, in the award categories of Visio and M365, since 2008.

Visio Blogs

  • Bill Morein (via Wayback Machine)
  • Chris Castillo (via Wayback Machine)
  • Chris Hopkins (via Wayback Machine)
  • David Parker
  • Eric Rockey
  • Jesse Phillips-Mead
  • John Marshall
  • Michel LAPLANE (FR)
  • Nikolay Belyh
  • Saveen Reddy (via Wayback Machine)
  • Visio Guy
  • Visio [Product] Blog
  • Visio Insights (via Wayback Machine)

Visio Resources

  • Developing Microsoft Visio Solutions
  • Visio Stencils at ShapeSource
  • Microsoft Visio YouTube Playlist
  • Visio (Product site)
  • Office 2010 Engineering
  • Visio 2016 SDK (Download)
  • Visio JavaScript API reference
  • VisioMVPs.org
Contact

visualSignals ltd
31 Riverview Grove
London, W4 3QL
United Kingdom

+44 (0) 208 078 9120

Around the Web

Copyright © visualSignals ltd 2025

Mastodon