I recently spent many hours over several days troubleshooting an issue in Visio wherein if I run VBA code on EventDrop for a given master shape that also has a custom property configured for “Ask on drop”, the dropped shape never pops up its dialog box for the custom property values. The specifics of my situation are much less important than the fact that even after some lengthy help system and documentation searching, not to mention Googling and searching in MSDN, I could find no mention of the phenomenon anywhere (if any reader has seen mention of this, please provide a pointer, perhaps my google-fu was bad these last few days).
The problem seems obvious in retrospect: if you’re running code in a shape when the shape is dropped on the page, apparently that code takes control of the Visio process before Visio itself pops up the ask on drop dialog, so the custom property data is never requested from the user. What makes this problem particularly pernicious is that anything that interrupts the execution of the VBA code while it’s running (like, for example, a breakpoint) allows the dialog to show, so it seemed like a phantom error for a while during my troubleshooting.
What seemed to me to be the obvious solution was to use Application.DoCmd( visCmdFormatCustPropEdit ) (or Application.DoCmd( 1312 ), since Visio automation code takes either a Visio constant or an integer) to force Visio to display the Customer Properties dialog. Two problems presented themselves with this approach: 1) placement of that call in the code matters a great deal, since what’s actually selected (i.e. the object that will provide the context for the Visio Edit Custom Properties action) is different depending on when in the drop process the code is called and 2) even when you have the right context, this command seems to throw an error message if either the OK or Cancel buttons are clicked without any other changes being made in the dialog (like if the user accepts the default value for the custom properties).
My solution ended up being somewhat of a hack but seems to be stable and does what I need it to do. I took a gander at Visio’s help for DoCmd and ended up at a help topic listing the supported constants used for commands in DoCmd (the online version of this topic is this list of Visio commands). I perused the list and selected one that seemed pretty innocuous; I’m using 1219/visCmdDRPointerTool, which activates the pointer tool, the default tool in the Visio drawing window. In my case this works fine since my users don’t typically change tools while working in my application. In other cases where keeping the selected tool may be important, running a command that toggles a setting and the running it again would work: an example of this is 1658/visCmdCustProp which toggles display of the custom properties list. Running Application.DoCmd( visCmdCustProp ) twice in quick succession would display and then hide the custom properties list with little effect on the user.