I consider the general topic of macros to be one big "duh" moment in my career. I spent literally years as an I-DEAS instructor telling students some variation on the following: "If you find yourself repeating the same steps over and over again, that's probably a good opportunity for a macro." Or, "if you don't like the way something works out of the box, you may be able to change it with a macro." Years. And yet, once I ventured out into the real world (post-SDRC), it still took me almost two years to write my first macro. It just never occurred to me. All it took was a little inspiration.
Inspiration took the form of a presentation I saw at the very first PLM World conference I attended. A bright young man named Daved Narajowski gave a very good presentation on customizing I-DEAS. This served as my first macro "ah-ha!" moment. I went back to my job and instantly identified several activities that involved repeated steps, and soon after my first macros were born.
Then I sat on my laurels. My fellow users were happy, and it didn't occur to me to press onward. I won't claim to be the most creative or observant person. Several more years went by before I attempted any more macros, inspired by yet another presentation, but this time at the SolidWorks conference. Even though the language is completely different, and some of the needs just don't apply, for some reason this inspired me to take another look at macros in I-DEAS. And this time around, I developed some seriously cool stuff that not only automated our own processes, but even addressed some obvious shortcomings in I-DEAS. I wish I had thought of them many years ago, because I had the need for a long time.
The bottom line here is to be diligent about identifying your needs. Can you turn 5 clicks into a single click? Can you find a task that people hate to do but is necessary, and take some or all of the pain out of it? Are your users constantly making a mistake that you can help them to avoid? Any of these questions, and there are certainly more to be asked, can serve as the inspiration for your macros. What can you do to make your job, and your fellow user's job, better? Get input from your users. Many of my programs were inspired by a coworker turning around saying "You know what would be nice? If the software could just do..." I took these moments as a challenge, and for the most part, I succeeded.
Identify your resources, and then milk them for everything they are worth. First of all, check your available documentation. I simply cannot stress enough how useful the I-DEAS Drafting Programmer's Guide in the online help is. I have several programs that exist today simply because I was reading through the list of available commands, and found some that looked interesting. I didn't really get into SolidWorks programming, and as such don't know what the online documentation is like, but having a larger audience means there are almost certainly books available on the topic. Training classes, too.
Don't overlook your user group. One of my earliest programs came into being with the help of sample code I received after making a request on the mailing list/forums for I-DEAS. I didn't really understand what it did, but was able to adapt it to my needs and it served dutifully for quite a while until I figured out a better way. That better way was actually provided when I made the original request, but I didn't understand what I was being told, and it took me a long time to come around and comprehend it. Chances are someone else has already attempted what you want to do, or something similar, and generally speaking the CAD community is pretty helpful.
Sit Down and Do It
Although this concept has really been frustrating me in the Mac/iPhone books I've been reading through, when it comes to macros you really will learn best by sitting down and doing it. Most programs that support macros also provide some means of recording your actions. You tell the software that you want to record a macro, you perform the desired steps, you stop recording, then you look at the resulting file. You may not understand every little detail that appears in the file, but by correlating to the steps you performed, you should get an idea of how the commands work.
One of the first macros I came up with had to do with creating a drawing and inserting a titleblock. After creating the new drawing, the steps were essentially the same. Select the symbol button, navigate to the desired symbol, and provide the insertion coordinates for the symbol. Recording those steps produced a file that looked something like this:
K: N "C:\documents\B_size.sym"
K: X "0"
K: Y "0"
E: **** END OF SESSION ****
For the most part, this looks like meaningless gibberish, so you have to correlate what you see to the actions you performed. In this case, the first thing I did was select the symbol command. The first line is X: II. I may not know what the X: means, but if I know my drafting behaviors well enough, I might be able to figure out what the II means. In this case, it is the mnemonic for the command, which is the keyboard equivalent to hitting the icon. You can see the mnemonics displayed whenever you pop open an icon stack, and the 2-letter combination is what you can type in. It probably stands for Insert Instance, in this case, since we are going to wind up with a symbol instance. I tend to equate the "ecks" sound in this context with "execute", so let's go with that. The first line says "execute the Insert Instance command," which correlates to my action of hitting the symbol button.
The next line looks like a file path, not sure what the K: or the N are. Pay attention to the interface, and the N actually corresponds to the field where you can type in the name of the symbol that you wish to use. N for name, easy enough. Still not sure about the K:. Won't worry about it. Next line has another K:, and no idea what the ^@ is. Oh, but as I was performing my steps, that's where I hit the middle mouse button to indicate I was done with a step. Then I see an X "0" and a Y "0", which must correlate to the coordinates where I inserted the symbol (0,0). Ok, these all seem to be text entry lines, effectively, so maybe the K stands for something like "keyboard." It starts to fall into place: X for executing a command, K for anything that is a keyboard or mouse entry. The ^@ corresponds to the middle mouse button, which is the same thing as the enter key, which is often the same thing as hitting a 'done' button in the interface. The ^$ corresponds to hitting the right mouse button, which in drafting is 'cancel.'
The documentation does help to clarify some of these things, but I felt it would be useful to go through the thought process to figure some of these things out on your own. I performed this action, the software recorded this line of text in the macro file. Therefore, that line of text probably corresponds to that action, a theory that is easy enough to test.
The thing to be mindful of when recording a macro is that you have to be very careful and deliberate about the actions you are performing. If you make a mistake when recording your macro, then the macro will always make that same mistake every time you run it. That's not useful. This is why it is helpful to know how to read the code that is produced. If you make a simple mistake, it might be a simple matter of removing one or two lines of text. If you make a major mistake, or don't know how to edit the file, you are probably better off starting over with a fresh recording.
You also have to be aware of what actions the recorder will capture. In the case of I-DEAS, any panning, zooming, or rotating (not in drafting, obviously) actions are recorded. This means that any fidgeting or adjusting you do while recording the macro will happen again every time you play it back. When viewing your macro file, if you see lines containing a whole bunch of numbers, those lines probably contain the coordinates that describe the motions you went through. You can test this for yourself pretty easily. Record yourself hitting the right mouse button three times. Then do it again, but pan after your first button hit, then zoom after your second button hit, and compare the resulting files.
Get Hungry For More
This hasn't been particularly detailed, and what details are here are geared towards I-DEAS. But, I have applied the general process to Excel when I needed to develop some Visual Basic (VB) macros. And based on the SolidWorks presentation I saw, the concepts apply there as well. Next time I'll get into some specifics, and some additional considerations you have to make when planning a macro.