Does anyone have some good VBA code practice tips for moving parts of solution in to a Visio Addin later? We want to start with VBA in a stencil then move the appropriate parts later in to an Add In using VB.NET. Ideally we make some choices in the code that reduce the amount of changes/recoding needed for those parts of the solution that are suitable to be moved in to an Add In.
I also heard that in Office/Visio 2019 the Office ribbon design has been changed, so I assume it is useful to take this in to account when setting up the ribbon/buttons in the add in. Need to read up on this.
Think modular. Create reasonable functions and subroutines that handle small single jobs, rather than a couple of very large routines that do a lot of things. This will make it easier to swap out to an Add-in (noting that VBA and VB.Net are two different languages). Separating your logic, your presentation and your user input will also help.
Yes AJD thank you, will follow this strategy. Are there important performance considerations in terms of what to put where?
In terms of breaking code into modules, usually there is no performance hit in doing so. The extra coding time is usually way offset by the improved ability to maintain the code.
Some advanced thinking about performance relate to how the Visio objects are referenced in VBA, and how much the code interpreter has to switch between the VBA model and the Visio model. I haven't seen any discussion on this from a Visio perspective but it is discussed a lot in the Excel context. Unless you are planning to do thousands of calculations, you may not notice too much of an issue. But, this is an advanced topic and I cannot do it justice in the post.
I often use classes, and I have used some with pre-computed values in an Excel job I have done. This can help with performance in some cases - but this really depends on what you want your code to do. Sometimes, pre-calculating and then using the same results often suits the outcome, and at other times calculating on the fly each time is what is required.
Hi,
Bit slow to this thread but I thought I'd add my tupence worth:
Full namespacing - VBA is very forgiving and so the temptation is to not qualify enums:
shp.SpatialRelation(otherShp, 0.5, visSpatialIncludeContainerShapes)
This works in VBA, and of course you have less code to read, but when you convert this to .net it won't compile. So I think it's worth the effort to fully qualify:
shp.SpatialRelation(otherShp, 0.5, Visio.VisSpatialRelationCodes.visSpatialIncludeContainerShapes)
This includes both the enum name and the 'Visio' prefix.
In VB.net you'll be able to add an alias like this:
Imports Visio = Microsoft.Office.Interop.Visio
and in C# (if you decide to go that way) it would be:
using Visio = Microsoft.Office.Interop.Visio
Either way, if your VBA is already qualified, then there's much less work later on.
Just to be clear, this isn't just about enums, but applies to all declarations - so favour Dim shp As Visio.Shape rather than Dim shp As Shape.
ThisDocument - if your intention is to move to an addin then I think I would try and avoid doing too much in the ThisDocument class in VBA. It's has some convenient ways of wiring up event handling, but my approach would be to treat it as a place for your start up code (if required) that will ultimately get transferred to ThisAddIn_Startup in the addin.
Events - if you might be targeting C# later on then you should avoid declaring events using the WithEvents keyword, which is a VB only construct. The ideal is to go for AddAdvise with and event sink class which is more work but also more efficient. Another consideration for events is what changes will be need to be made to calls from the ShapeSheet to your code. With VBA you might want to use the CALLTHIS function but this won't work for addins. An alternative to consider might be the use of the QUEUEMARKEREVENT function to raise....QueueMarker events. Here you would raise an event from the ShapeSheet that could be interpreted by both VBA and an addin. It would have the benefit of potentially later being able to swap in a new non-code stencil and existing legacy documents would continue to function as before (at least in terms of event firing). MarkerEvents aren't the solution to everything so you'd want to weigh the benefits or otherwise of using them against the task of 'converting' existing documents later on.
Ribbon - Your point about the ribbon changes is a good one, and I think here the ideal would be to favour builtin idMso name-based icons rather than your own custom ones as they are likely to change automatically as the new ones emerge. I have a PowerPoint addin that has changed to the new look with no work on my part at all.
File extensions - If your plan is to move from code in the stencil to an addin based solution, make sure that any code that relies on inspecting file types can handle both .vssm and .vssx so that no changes are required when they do.
Performance - Personally, I would try not to worry about performance until you discover there's a problem. If you do find that there's an issue, then there's lots of options. Both VBA and VSTO addins run in the same process as the application so you're already at an advantage, but I would certainly favour readability over speed, right up until the point where you've identified it as a significant problem.
Anyway, I hope that's helpful. It's just my perspective and I'm sure there's lots of other approaches that I may have missed.
Best regards
John
Dear John,
Thank you so much for your response to my question, this is very useful guidance for me.
Developing with VBA then moving functionality in to an addin later with some minor modifications for VB.NET is a very effective workflow for us.
I am also very interested in your take on how Visio Online Editing and Javascript code access to the Visio Online (Editing) functionality is developing and will develop in 2019.