Last edit: 05-03-17 Graham Wideman
|
Last edit: 05-03-17 Graham Wideman |
Visio |
| GW Visio Object Explorer: How To Use Article created: 99-01-05 |
Getting StartedGWVisExp is not alert to changes the user makes in Visio. If you have studied the workings of Visio, you may realize that Visio exposes an assortment of "Events", which another app could register for to receive a notification of changes. However, I elected not to use that aspect of Visio for this tool for several reasons:
So, as a result, GWVisExp basically takes a snapshot of the state of Visio, reading the child nodes afresh each time you open a parent, or refreshing everything if you hit the Refresh button.
If you prefer, you can set GWVisExp to auto-refresh at regular intervals. This is good if you are monitoring certain properties as you modify a document in Visio. On the other hand, it's disruptive if you are trying to use GWVisExp's user interface, or if you are using a slow machine.
In addition, I should note that if Visio has a modal dialog open, then it refuses to answer an add-on's OLE Automation requests... so refresh during that time is not sensible.
| Icon | Meaning |
 |
A Visio Object (other than ones shown below). Examples: IVApplication, IVPage |
 |
A Visio Object that implements a Collection (typically a plural-named property -- as in Pages). Collections have an Item property (containing the actual array of items in the collection). The Item property also uses this icon. |
 |
A property of some simple type, basically integer or string. (The icon is supposed to look like a slot.) |
 |
An array of simple-type properties. |
 |
A simple property that's particularly useful for identifying the object that owns it. For example IVPage.Name. |
 |
The CellsSRC property of IVShape. Open this to access all the shapesheet cells. Note that several properties that implement other ways to access cells and rows (eg: by name) are not implemented by GWVisExp. See notes. |
 |
A Section within the shapesheet |
 |
A Row within the shapesheet |
 |
A Cell (ie: IVCell, a specific CellsSRC[Section, Row, Col]). |
When working with shape internals (particularly groups) it can be handy to pop open several GWVisExp windows, one for each shape. Also handy is the ability to selectively check "Stay On Top"... for quick jumping from Visio drawing to cell-editing (and without the stomach-churning window-jumping-up-and-down that occurs in Visio due to changing toolbars as you click between drawing and shapesheet -- sigh, definitely looking forward to floating toolbars!). One thing you cannot do with GWVisExp is to add or delete rows and sections in the ShapeSheet cells (eg: Geometry).
Right click on a property to pop up an edit window. Note that you can right-click on a cell to edit its value (you don't need to expand the cell node and edit the cell's Formula property.)
Refresh: While you have the node-edit window open, note that as you change a node's value (including a Cell) only the one node being edited gets updated in the associated treeview. When you close the node-edit window then the entire tree gets updated. There is no impact on the Visio side, and this avoids lengthy waits to refresh the whole display while you still have the edit window open and may be wanting to try a variety of values. It's simply important to remember this in the cases where changing one cell causes Visio to change other cells -- those changes won't be displayed in other GWVisExp tree windows until you close the node-edit window.
Guard: If you are editing the Formula property of a Cell, then if the formula includes the Guard function you will not be able to save your edits... which is as it should be. You also cannot workaround this by editing the FormulaForce property, as it is WriteOnly (hence GWVisExp can't retrieve a value.) Instead, work around this by editing the Cell node, which uses Formula to read and FormulaForce to write.
It's sometimes useful to see exactly the bytes stored in a Visio string property, as in the case of examining a shape's text which contains a "field". In the example you can see exactly what Visio stored for a document filename field (characters 11 through 14).
| Date | Version | Note |
| 99-01-26 | 1.0 | Released. |
| 99-01-25 | 1.0 | DockedStencils: The list of Docked Stencils would seem to be a nice Property of a Window, however it's only provided by Visio as a function. For convenience I've implemented it to look like a Property. |
| 99-01-18 | 1.0 | Edit-Node
Wrinkles When Editing Masters: When a Master's Shapes (or the Shape's Cells) are edited, the issue arises as to how to "push" the changes to all the shapes that "inherit" from that Master. Visio resolves that by requiring programmers to make a snapshot of the Master, make changes to the snapshot, and then post those changes back when they are complete. This is done using the Master.Open and Master.Close functions. Open provides the snapshot object, and Close tells Visio to merge the changes into the original Master, then update all dependent Shapes, and update the actual display. (It appears that this is not needed for the direct properties of the Master, eg: Master.PatternFlags). GWVisExp therefore uses a special procedure to edit Cells and Properties of Shapes if they are contained in a Master, involving the Master Open and Close apparatus. Situations can occur where a particular Master gets locked, for example if it's already opened by some other program, or if a program has Opened it but forgotten to Close it. This can arise if you attempt to edit a Master using GWVisExp that you also have open for editing in Visio. One way or another you can arrive at a conflict, and can even get Visio into a state where a Master is stuck open. There is probably some pattern to this which could be avoided, but I haven't investigated fully. In any case, if GWVisExp tries to use Master.Open etc, but detects that it somehow failed, it will attempt instead to write the property using the original object (the data gets written, but the display is not updated, and dependent shapes may not get their values updated), and also provides an error message box. If this happens, the workaround is to close the document and reopen it. |
| 99-01-10 | 1.0 | Exceptions: Sometimes a node label will show an "EXCEPTION" message, followed by some description. This may happen if Visio thinks that the object for that node is no longer valid -- ie: you are trying to expand a node that pertains to an object that's been deleted in Visio. In other cases, an exception is a "normal" return from some properties, for example the Shape.Hyperlink property when it's empty. |
| 99-01-10 | 1.0 | LUTs: You may encounter the term LUT: This simply refers to "Look-Up Table", used in GWVisExp to look up the appropriate constant values for integer properties and array indexes. |
| 99-01-10 | 1.0 | Unintuitive Node
Delete Behavior: If you are inspecting a collection of objects, say three Shapes
on a Page, and you delete, say, the first shape, then on the next Refresh GWVisExp will
correctly show just the two shapes remaining. If you had expanded the first shape,
then after refresh the first shape displayed in GWVisExp will continued to be expanded,
showing what used to be the second shape. The info is correct, but you might easily
not realize that the expanded node is not showing the same shape that it did before --
especially if you've dug all the way down into the Cells. The same sort of thing
happens if you use Bring To Front or Send To Back, thus changing the order of the shapes. This can be easily guarded against by selecting the object of interest (in this case a particular shape) and opening a new tree window dedicated to that object. (There's a good reason for this sub-optimal feature -- but not worth going into here. Ie: this is not one of those cases where it would be easier to program around it than to write up the explanation!) |
| 99-01-10 | 1.0 | Variant Nodes: GWVisExp does not open generic "Variant", "IUnknown" and "OLEVariant" nodes, of which there are very few. |
| 99-01-10 | 1.0 | Visio's FieldCategory/FieldCode fields are a little tricky (interpretation of FieldCode depends on FieldCategory), and currently the lookup is not implemented properly (the numeric data is correct though). In any case, it's not clear these are very useful compared to the embedded field codes. (There is in fact a bug in Visio 5.0c and below, relating to interpretation of fields when copying and pasting to other apps -- see my Visio bug list.) |
| 99-01-10 | 1.0 | With Visio 4.5... there may be a few properties that report "Exception" (in addition to the few in 5.0), these may be ones not implemented in Visio 4.5. Sorry, haven't checked this in detail. |
Go to: Up to:
[Visio Explorer] Up to: [Visio]