Ability to edit/export/import ShapeSheet as text

Started by gwideman, January 05, 2012, 10:58:29 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Basically this is a suggestion to be able to edit ShapeSheets as text, which for many operations would be fantastically much faster than editing in the ShapeSheet window, particularly for creating or rearranging very repetitive code.

The idea would be to be able to flip to a "plain text view" of the ShapeSheet window.  This could be simply the XML view, for which presumably to-XML and from-XML code is already written. Preferably it could be a more literal rendition of what we see in the ShapeSheet window, for example:

User.MySpecialCell.Value = (Width + 1 in) * 37

... or whatever.

This would be extremely analogous to:

a) In MS Access, the text (ie: SQL) view of queries.  Normally the user edits the graphical query view, but can switch to SQL view.

b) WYSIWYG HTML editors that offer a raw-text HTML editing alternative.

As with those analogous cases, it's obviously quite possible that the user will edit the text into a state that doesn't make sense when converted back to structured ShapeSheet data.  The "switch to ShapeSheet view" command should point out where the error is, and give the user the chance to edit and try again, or cancel and revert to the pre-edited state.

(I should note that for Visio 2003 I experimented with the possibility of using Automation to request XML from a selected shape, with the idea of editing it, and then sending it back to Visio.  This idea was hampered by the issue that a shape's XML came with a large amount of additional XML that the shape ultimately referenced.  This comprehensive blob of data make sense as something self-sufficient enough to, for example, paste elsewhere. But it's way overkill for simply editing an existing shape in its existing context.)

Extending this thought, it would be helpful to be able to export and import such "text format shapesheets" for editing by external tools, or as documentation.  (Again, if import fails, a simple indication of error location would be fine for the developer to live with. Ie: if the imported data references context that the importing document doesn't have, well too bad for the user.)

-- Graham