Inventor's implementation of VBA supports two types of VBA projects; document projects and external projects. They're defined by where the project is saved. Document VBA projects are saved within Inventor documents, parts, assemblies, etc. External projects are saved as individual .ivb files. Using the File tab of the Application Options dialog you can specify one external project to be loaded automatically when Inventor starts up. This VBA project is frequently referred to as the application project.
When VBA was integrated into Inventor we looked at other VBA integrations for ideas. All of the applications that supported VBA that I had used at the time all used the idea of document projects so it seemed like that was something we needed to provide as part of Inventor's implementation. However, when I had used some of these applications that only had document projects I didn't like them because it made maintaining code almost impossible. For example, I was writing a reasonably large program in one of the applications and it was stored within a document. I would copy that document to use the program with other sets of data. When I wanted to make a fix or enhancement to the program I had multiple copies of it and didn't know which version of the program existed where. As a result of this frustration we also added support for external projects in Inventor's implementation of VBA.
A feature of the document macros that Word and Excel supported that seemed good was the idea of automatic macros. These are macros with a particular name that are run automatically when something happens in the application. For example, when a document is opened or saved a macro is run. This functionality makes it very easy for someone with limited programming experience to write a simple macro to respond to these events in Inventor.
A couple of releases after we added VBA to Inventor we started getting reports of some problems. The problem turned out to be a resource issue with VBA. People were creating document projects that used automatic macros and were using these Inventor documents that contained these projects as their templates. That meant that every file they created had a VBA document project. When a large assembly is loaded all of the referenced documents are also loaded, and in the case of these documents also meant loading the embedded VBA projects. It turns out that VBA has a limit to the number of VBA projects that can be loaded.
The other significant problem to having document macros in a template is that it creates the problem I already talked about of having your program duplicated in all your documents making it very difficult to fix or enhance that program. There is also another problem that recently came up with document projects and 64 bit Inventor.
My advice is: DO NOT USE document projects. The one exception to this is if you're writing a program that is very specific to a single document. For example if you have a part and write a specific program to work with only that part. In this case it's convenient to package the program with the document rather than worry about passing an additional file with it.
External VBA projects should provide most of the functionality you would want and also provide the additional capability that you can create toolbar buttons to run the macros contained within them. What external VBA projects don't provide is the ability to do the equivalent of automatic macros. The best answer for this is to create an Add-In. (There have been some Add-In utilities written that add support for automatic macros to VBA external projects but I've found for most people that these end up being confusing because they don't understand how they work and as a result don't know how to debug and diagnose problems when they occur.) An Add-In allows you to do anything you could do in VBA and more. The downside of an Add-In is that there's a higher learning curve to getting started.
In my next posting I'll cover what's required to create an Add-In that replaces an existing automatic macro.
Leave a Reply