Now here’s a post about a niche aspect of Visio, but I’ve delved into this registry setting a few times and thought I’d explore what’s inside…
[WARNING – This post describes details of the registry and if you're not completely happy with what that is then I strongly recommend moving on to the next post. If that doesn’t put you off then of course make sure you backup the registry before making any changes.]
All of column widths within the ShapeSheet have default values. When you change a column width by dragging one of the vertical lines the new custom value that you’ve set (in the drag operation) is stored in the registry and so allows you to persist your settings between sessions. Visio is a responsible citizen and so only stores your custom changes rather than a set for the entire ShapeSheet.
Occasionally, by which I mean that this has only happened twice in the last decade, some column widths get out of whack for one reason or another and knowing where to look can help get you out of trouble. For example, quite a few years ago I had one ShapeSheet column that somehow got expanded to well beyond any scrollable limits, and then more recently, when I upgraded to a new 4K monitor, the LocPinY cell lost its vertical alignment with its LocPinX friend.
The simplest way to restore the default values is to delete one or all of the values from the following key:
HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Visio\SheetColumnWidths
where, 15.0 is the version you’ve installed on your system (2013 in my case).
Make sure that all instances of Visio are closed when you do this as Visio writes any number of custom values (SheetColumnWidths included) to the registry as it closes.
What does it all mean?
Once you open up the SheetColumnWidths key, you’ll see something like this:
I’ve often looked at this and wondered what pattern’s are used to map the name column to the actual ShapeSheet cells and since I like puzzles, I thought I’d try and work out what’s going on.
Broadly, the Name column identifies the cell and the Data column a custom width value in pixels. One thing to realise is that there are basically two types of Section as far as ShapeSheet column widths are concerned: one with different row types and one with similar rows. For example, the User, Shape Data and Connection Points sections all contain a series of rows that share exactly the same column pattern, whereas Shape Transform, Protection and Miscellaneous contain rows with multiple column configurations. In his 2003 book, Graham Wideman describes the section types as MultiUnique (multiple unique rows) and MultiHomo (multiple homogeneous rows), which is a great way to understand the underlying structure and the UI that we’re dealing with here.
Unique Row Sections
For the unique row sections the Name column in the registry is in the following structure:
The first number identifies the section and I’ll list those in a minute. (Note that this is not related to the VisSectionIndices enums.)
The second number identifies which row (zero based) this particular column width is focused on.
The third number is for the column index – again this is zero based from the left.
The final number is what I’m describing as the Type and appears to be as follows:
| Type Number | Description |
| 1 | section title |
| 2 | column heading |
| 4 | indexed row number |
| 8 | cell name label |
| 16 | cell value |
| 32 | blank non-data cell |
| 64 | indexed row name |
Using this scheme, you can see that the above 2:2:3:16 sequence identifies the PinY value column, as the initial ‘2’ is the section index for the Shape Transform section.
As I mentioned, the section indices stored in the registry aren’t the same as the enum values you’d use when writing code, so here’s a list that I’ve deduced / put together:
Homogeneous Row Sections
Sections with indexed rows or a series of similar rows work more like a normal table and given that following rows (after the title row) all follow the same column pattern, the row is omitted from the Name number sequence. For example, a name identifying the value cells column in the User-defined cells section would look like this:
One section that appears to get special treatment is the Geometry section. Here, the section can be seen to be comprised of two parts: the first three rows including the title, the .NoFill / .NoLine row and the geometry column headings X, Y etc. The second part is the series of geometry segment rows that are appended by a ‘geo’ identifier at the end of the Name sequence.
Here’s an example of a geometry section and you can see in the registry overlay that the two ‘geo’ values (the index number column and following row type label) both sum to the pixel width of the column above:
7:0:4:geo (19) + 7:1:8:geo (33) = 7:0:8 (52)
So there you are. You will very likely live a happy and fulfilled life without ever having to look at this registry key, but if you do then hopefully this post will help.