There certainly are many choices for code development tools at your disposal out there. Visual Basic is the most popular language for CATIA automation programming but it has many flavors such as VBScript, VBA, VB6 and VB.NET and each has its own development environment / editing tools. I use all of these tools at different times depending on the requirements of the project I am developing. However, I find that I almost always tend to do a lot of the code development in VBA even if the final code ends up in a different environment such as VB.NET.
While I have found VBA to be a very efficient tool to develop my code, I have noticed that a lot of people are still developing their programs as scripts in the macro editor that is built into CATIA or some other form of simple text editor. While this works well enough for a very short and sweet macro, as the length and complexity of your program grows, these tools really become terribly inefficient. In this article, I am going to going to point out some features that I find very useful in the CATIA VBA editor and that I think will make your life a whole lot easier if you are one of those people who still spends most of their time in the CATIA macro editor. Even if you are already familiar with VBA, skim through and maybe you can pick up a few tricks.
Creating a VBA Project
If you have never used VBA, you should understand how to open the VBA editor and create a new VBA project. The easiest method is to press ALT – F11 which will open the VBA editor. If you have not already created a VBA project library, you will be prompted to create a new one. It’s really very simple, but if you need more information about this, just visit the CATIA help documentation.
Ok, now for the ten reasons…
Reason #1 – The Compiler
The worst thing that can happen in any program is for the end user to get an unhandled error thrown up in their face and the program halts. Probably the second worst thing is for you to spend way more time than you need to testing and debugging your program to find and correct bugs. There are many things that cause bugs but probably the most common types of are bad math (like dividing by zero), bad logic (like an infinite loop) and syntax errors. While the first two are hard to detect without running the program, the third one, syntax errors are very easy to avoid in VBA even before you run any code.
This is accomplished by letting the compiler quickly check for simple mistakes such as a misspelled property or method, forgetting a Set statement, trying to call a method that is not supported by an object or passing the wrong data type to another procedure. You might think it is easy to just run your program and find these things, but often times a program will have many paths it can take because of logic such as if-then statements so you would actually need to test every one of those paths to find these potential bugs. Instead, the compiler will check these problems in all of your code almost instantaneously any time you want before you even run the program.
To really take full advantage of the compiler, you need to declare (Dim) all of your variables along with proper data types and use Option Explicit at the beginning of each code module. I preach this all the time because it really takes very little extra time to do and the payback is big because you can identify and fix issues so fast. Option Explicit is just an option that tells the compiler that every variable in that code module must be declared. That sounds like a pain, but let’s say you misspell a variable somewhere. The compiler will flag that variable as a problem because it is not declared. How else do you find problems like this…at run-time?
Unfortunately, Option Explicit doesn’t force you to declare the type of the variable but I still recommend doing so because it allows the compiler to also check whether the correct data types are being passed around your program. Some other languages like VB.NET also have Option Strict which forces you to declare all variables and their types but unfortunately this is not supported in VBA.
To compile your code, simply go to the Debug drop down menu and choose Compile <project name>.
Reason #2 – Intellisense
Intellisense is the name of that handy little feature that gives you a scrolling list of the properties and methods when you type a dot (.) after an object variable.
This allows you to easily browse and find the item you need without always having to refer to the object browser or help documentation to look it up. Also, when the Intellisense list appears, if you start typing the name of the property or method, it will go right to it in the list and if you then press the space bar, the full name will be added to your code without having to type it all in. Intellisense can also be used to provide a preview of the arguments that are expected by other procedures as you type them in.
To really take full advantage of Intellisense, you will need to declare your variables along with their data types. Specifying the data type is what allows Intellisense to provide you with a list of the supported properties and methods.
Reason #3 – Quick Info
Quick Info is a handy tool that helps you identify what data type any variable is in your program as well as it’s scope. If you are not familiar with the concept of scope, it simply means where in your program that variable can be accessed. Depending on how and where a variable is declared, it might be available only within that module, only within a specific subroutine, throughout the entire project, etc. This is referred to as the scope of that variable.
Simply place the cursor on the variable name then press CTRL – I
Again, this only works if the variable has been declared with a data type. Are you convinced yet that you should fully declare all of your variables?
Reason #4 – Debugging Tools
One of the most compelling reasons to use the VBA editor is it’s built in debugging tools. For example, you can set a break point on any line of code (usually where you suspect there might be a problem) and when the program runs, it will pause right before it executes that line of code. This gives you an opportunity to snoop around and do things like checking the value of different variables to see what the problem is. You can create a watch on a variable. When your code pauses at a break point, you can then look at the watch to inspect it’s value or even the values of all its properties if that variable is an object. You might also want to use the immediate window to execute a single line of code to reset some value or execute some action.
There are really just too many different debugging capabilities and techniques to explain in this article. If you haven’t used similar tools in the past, search for “VBA debugging tutorial” in google and you will find many good resources.
Here are a couple of decent links that I found,
Reason #5 – Code Organization and Reuse
A VBA project can be thought of sort of like a container that can hold many separate “pieces” that make up the overall solution. Those pieces may be standard modules, class modules or userforms. Here, I am going to focus on standard modules just to point out how they can help you to better organize larger projects and also help you to reuse code.
Think of a standard module almost like a separate document where you can place code. Realize that a module is not physically a separate document on the file system – instead it is stored inside a single VBA project file (.catvba file) with all the other modules. In a module, you can declare variables, add procedures (subs and functions) and that code can generally be accessed from any other module or userform in the project.
So in terms of code organization, modules are great because they allow you to divide up your project in a logical way. I generally group closely related procedures in their own module and I also create other separate modules whenever I think some code is likely to be reused again. For example, I might have a math module that contains all kinds of mathematical functions or a text module that contains different handy procedures for reading and writing text files. It is very likely that I am going to reuse these again and again in other projects so I will definitely break these out into separate modules. So a project might be broken down like this:
In the above example, modClearanceZones contains very specific code written just for this project. However, the others contain generic code that I want to reuse in the future. When this project is complete, I will right click on each of these modules and export them to a common file system folder. Then in future projects, I can simply create just a couple of new modules to manage only the new pieces of code that are specific to the project and then simply import some of those “common” modules as required. The code in those common modules is already done and tested! Over time, as I add additional procedures to an existing “common” module, I just export it back to that common folder once that code is stable and proven. So, not only do modules make it easy to reuse existing code but they also make it easy to logically organize the code in your project so it is easier to find your way around the overall project. I think you will agree this is far better than writing a program all inside a single script file.
Reason #6 – Navigation
So we just learned about modules which certainly can help you navigate your project more easily. However, there are many other things in VBA that enhance navigation.
For example, at the top of every module window you will see drop down combo boxes. These allow you to quickly jump directly to a specific procedure without having to scroll your way up or down looking for it. This is a huge time saver.
Another thing I often use is the Split capability (Window menu – Split). This allows you to split a single module into two separate regions that can scroll separately. This is really nice for longer chunks of code so you can view two different regions at the same time. I tend to declare all of my variables at the start of each procedure, so often I split the window so that I can see and add to my variable declarations while I am coding further down in that procedure.
Reason #7 – Access to Help and the Object Browser
I frequently refer to both the CATIA automation help documentation and the automation type libraries while developing programs. You are probably already familiar with the help documentation, but you might not know that you can directly access specific help topics right from your code if you use VBA. Simply place your cursor on a variable declaration or an object property or method and press F1 and you will be taken directly to the specific help for that API. Now that is convenient!
If you have spent any time browsing the CATIA help documentation, you have probably noticed that there are many undocumented APIs. This is where the object browser becomes your best friend. The object browser will allow you to see every API that has been exposed for automation programming. I will often browse to a specific class to see all of the properties and methods it supports. Often you will see additional items that are not covered in the help documentation which is great. You might just have to play around a bit in some cases to figure out how to use them.
Also, the CATIA automation object model is built on the concept of inheritance which means that there is a hierarchy of more and more specific classes that each inherit some of their functionality from more generic (base) classes. That is what you see at the top of each of the help documentation pages.
I pointed this out because the help documentation only shows the properties and methods that are specific to the class you are looking at, not those that it inherited from some other base class. In most cases a class will support many more members but you have to click up through that tree at the top of each page and browse each of classes to see all of them. You can see this below where I show three of the inherited classes and that you need to view on separate help pages to see the supported members. This is a pain in the neck.
I have one last thing to point out about object browsers in CATIA, then we can move on. You might have noticed there is also an object browser available when you are in the default CATIA macro editor. Although it is convenient to have an object browser in the macro editor, it is missing some important features so you may still want to refer to the VBA object browser. For example, it does not show inherited members (as discussed above) and cannot take you directly to the help docs for the selected API by pressing F1.
Reason #8 – Readability
If you spend even a little bit of time using VBA, you have to admit that it does a pretty nice job of making your code easy to read. Mainly, I am talking about the separate coloring of things like comments, keywords, general text, etc. This simple color coding makes it so much easier to read thru code than when everything is black. Also, if for some reason you want to change the default color scheme, it can be done in the Tools-Options dialog.
I also like the horizontal lines that are automatically drawn to show where a new procedures start. This gives nice visual breaks when you are scrolling through your code.
Reason #9 – Indent/Outdent
We have all been there at one point in time or another – you either need to indent many lines of code to keep it readable when you have loops or conditional statements. There are also many times when you might need to remove some indenting for many lines of code. This is equally painful – you must go line by line and place the cursor then press delete. Luckily, VBA makes indenting and outdenting a breeze. Simply select all the lines of code you want and press TAB to indent or press SHIFT-TAB to outdent. Beautiful.
Reason #10 – Search/Replace
The search and replace tools in VBA are not perfect but can still easily handle most tasks. For example, you can specify whether to search the entire project, only in the current module or only in the current procedure. You can also change the search direction and case sensitivity. It also remembers previous searches (just drop the combo box to scroll through them) and it has replace capabilities. Simple features, but they sure do make coding much easier.
For sure if you are an experienced programmer you are very familiar with the things I pointed out above. Also, let’s be honest – VBA isn’t the greatest development environment by any stretch of the imagination. My favorite has got to be .NET Visual Studio – it is really impresive. However, even when I develop a project in .NET, I still build a lot of the code in VBA first then move it to .NET and reformat it a bit once it is working. The reason for using VBA is that I have access to all of the features listed in this article as well as recording and insert object resolution capabilities.
Anyway, my goal in this article was to introduce some VBA capabilities to those who are not familiar with it. If you fall into this category, I hope I have convinced you to give VBA a closer look. For the rest of you, maybe you picked up a few new things.
I’m sure there are quite a few additional things that I didn’t mention above. I just pointed out ten items that I use heavily when I develop programs for CATIA in VBA. If there are other things you would like to share with others, feel free to add a comment below.