Disabling Visio built-in commands

Normally it is not a good idea to do the above. But anyways, what if have to? Here is the list of options you have with Visio to disable the built-in commands. Some of which may be well pretty obvious while others may be not that well known.

1. Disabling using custom UI (ribbon xml)

You can disable them using ribbon xml. You can do so in your template (so that when your template loads, the command set is changed accordingly), and you can do so “globally” by writing an add-in which provides a ribbon.

The advantage of the approach is that it is documented and works fine if you just want to disable some command permanently for your solution/template. Also it will disable command in all it’s form – in all menus, using any shortcuts. There are also disadvantages though – it does not allow you to disable/enable built-in commands dynamically, and it works only for Visio version which has this ribbon – i.e. Visio 2010 and above.

To use this approach for a document, you should equip the document with custom ribbon, and in this ribbon you should just define which commands should be disabled. The same for the add-in: you should just add to your ribbon declaration list of commands to disable:

   <customUI onLoad="RibbonOnLoad"
         xmlns="http://schemas.microsoft.com/office/2009/07/customui">
         <commands>
           <command idMso="PictureInsertFromFile" enabled="false"/>
           <command idMso="ChartInsert" enabled="false"/>
       </commands>
   </customUI>

Commands “Insert picture” and “Insert chart” will be disabled:

2-22-2015 3-32-57 PM

To add custom this ui to a Visio document, you can use for example Office Custom UI Editor. Note that for Visio that would work only with .vsdx (2013+ files), which use standard open xml format. For earlier versions, you can inject the above XML using VBA, by setting Document.CustomUI property to set that XML. More detailed information about customization with xml can be found here for example.

Disabling using group policy.

You can also disable commands using local/domain policies. That is, you can simply define a policy to disable a specific command (by it’s id). This technique is primarily intended for use in organisations. Basically it works as following: You download the administrative templates (link is for Visio 2013, but there are also templates for all versions), unpack them to %systemroot%\PolicyDefinitions, then just open the the Group Policy editor (gpedit.msc), navigate to the “commands to disable”, and enter the command id. Basically, the policies are just registry settings (under HKCU\Software\Policies) which are applied to the user/computer.

For example, to disable “Insert Object” command you need to add it’s command id “546”. The ids of commands you can find using for example the free builtin control scaner tool.

3-1-2015 9-30-42 PM

There are a lot more things you can do with policies (e.g. set a user’s category or set trusted locations for templates). Read more about this possibility here:
Use Group Policy to disable user interface items and shortcut keys in Office

Disabling using API / ribbon callbacks.

You can disable commands by customizing user interface (hiding buttons, overriding keyboard shortcuts, etc). You can do that both using ribbon and using Visio API. The approach is pretty much straightforward – you get UI controls (e.g. buttons/menu items/keyboard shortcuts) programmatically and disable them.

In Visio 2010+, you can programmatically access the controls using three (sic!) different APIs (just like Perl’s motto – there is always more than one way to do it). These are – the antique one (UIObject), the old one (CommandBars), and the new one (RibbonX). The first two are rather plain – you find a control you need to disable by it’s id. Using the third one, you re-declare a control you want to disable in the XML with Microsoft’s id (it looks like idMso=) and set enabled=false. This could allow you more granularity from one side – you can disable command in one place, but keep it in another, – but from the other side, usually this does not make that much sense.

Subclassing the application window

This “technique” assumes intercepting WM_COMMAND message on application level (available for an in-process add-in only). All Visio commands (well, almost all) are routed through Visio main window; that means, that for each command main window gets WM_COMMAND message with corresponding command id. You can subclass main window, monitor command messages, and filter them as you wish. This is the most hardcore way, but in some specific cases there may, well, be no other options. For example, if you want to intercept commands like “Save” before Visio processes it, and do something completely different instead (re-purpose).

Leave a Reply