Tuesday, December 16, 2008

Macro Intermediates

The previous post covered some basics that I think apply to pretty much any macro environment. That may be true for what I want to talk about next, but I'm really going to have to shift this towards I-DEAS to do it any justice.


One of the key decisions to make in planning a macro is when (or how) it is going to run. This is a little bit of a chicken-and-egg situation, because what the macro does may dictate when it needs to be run, or you may need to change what the macro does.

Generally speaking, there are two different options regarding when a macro will run. I'm going to use the term 'trigger' to describe a macro being run. You can either have the user trigger the macro manually, or the software may provide some options for firing automatically. Which trigger to go with is highly dependent on what the program does. Let's use a ridiculous example of a program that deletes all of the dimensions on a print. You want that to be a manual choice. Chances are your users will get angry if that runs automatically.

Unfortunately, macros that require a user to manually run them are really easy to forget. People get in a hurry, your fancy new macro is different than how they've been running the software for years, so even though it does indeed save them time and trouble, it doesn't get run. There are some things you can do to improve the likelihood of the macro being used, such as making a custom icon panel that puts custom buttons in place of the standard ones, but at the end of the day you just can't guarantee it.


I don't currently have access to I-DEAS to be able to take any screen shots, so I'll just have to refer to the online help for how to do some of these things. In Drafting, you have the ability to add extra icon panels. You can create icons on custom panels (you can't mess with the built-in panels) that correspond to several kinds of activities, in this case triggering a macro.

I've mentioned that the original macros I wrote had to do with creating a drawing. Before my macros, this was a multi-step process. You had to create the new drawing, choose your options and size, then import the titleblock symbol and get it located. I wanted this to be a single click, and I wanted people to use it. There is no reliable action that I can refer to in order to assume automatically that a user wants to create a drawing, so this had to be a manually run program.

Wanting the action to be a single click forced my hand on the design of the macro. I-DEAS does provide decent means for interacting with the user within a macro, so I could have created a single 'create drawing' program that then prompted the user to select the desired size. However, this would have required 3 clicks (hit icon, select size, done). The only way I could make it be a single click was to have separate programs: 'create B size', 'create C size', and so on. Four programs instead of one (and thus four buttons instead of one), which I really didn't want, but I didn't have a choice. Bottom line, the user could create a drawing with a single click, so at least that part of the mission was accomplished.

Now to make sure that people use them. You can do some devious things with custom icon panels. As already mentioned, you can add icons, but more importantly you can add them to any icon stack. Users are used to going to the upper left stack for the Create Drawing command, so by putting my new macros in that same stack, I've placed them so that the user will see them when they go looking for the old command. You can also remove icons, even the built-in commands. Again, you cannot mess with the built-in icon panels, but you can do whatever you want with the custom panels (I might be wrong about this behavior, but it is just as well if you assume I'm right and leave the default panels alone). I was going to remove the Create Drawing command altogether, but I chickened out because some users had an occasional need to make custom sizes, and I didn't want to deal with the support hassle of reminding them to return to the built-in panel to find the command. What I did was reorder the icons in the stack so that Create Drawing was at the bottom. It's there if anyone needs it, but mostly out of mind, and my shiny new commands are at the top.

There is a certain psychology that you have to employ to get compliance out of your users. In this case, running the macros is technically a manual choice, but through some crafty user interface tricks, I was able to achieve a high degree of compliance.


There are certain categories of macros that are probably ok to run automatically. For example, setup types of things; define custom colors, define layers (ick!), flip various setting toggles, even define custom commands, and so on. The main question you need to answer is what automatic triggers are available.

In my limited experience, the available automatic triggers are highly dependent on the system being used. For example, I don't know how to automatically trigger a macro in Excel, though I have to assume it is possible given the warnings that are always associated with Excel files that contain macros. The only SolidWorks one that I definitely know exists triggers when a user hits the save button, but there are probably more. That's a pretty good one actually, as you can expect that users will be saving on a regular basis, and thus your program will be run frequently.

I-DEAS provides one major trigger point, and then a couple of minor ones. A userprof.prg macro placed in your I-DEAS user home folder will be triggered every time that a model file is created or opened. That David guy I mentioned before gave me a really cool userprof that he had inherited and extended. The program creates a nice pallet of custom colors, and then defines a variety of other settings, even some shortcut commands. For example, to set a white background, he can type "bkw", and then to turn it back to black "bkb". I added one that basically shuts off all display filters for maximum assembly performance called "noshow". I made another one called "us" that does a Complete Update followed by a Show Free on the entire assembly on the workbench. Just handy little things that I always want to have, therefore placed in the userprof and run each time I open a model file.

The minor trigger points are hiding in the masterdrafting.cfg file. Locate that, then read through until you find the following section:

userprof 1 () ! After Create Drawing, before Done
userprof 2 () ! After Put Away
userprof 3 () ! After Create Drawing and first Done
userprof 4 () ! After Get, Import, etc. of pre-existing drawing
userprof 9 () ! After Update
userprof 10 () ! Obsolete
userprof 11 () ! Obsolete
userprof 14 () ! Obsolete
userprof 15 () ! Obsolete

The description after the exclamation mark tells when the program will trigger. You put a program inside the parentheses. For example, if you wanted a program to trigger every time a drawing is created, do this:

userprof 3 (C:\dwg_setup.prg) ! After Create Drawing and first Done

I hadn't considered "upon save" as an option until I learned about it in SolidWorks, and now that I know about it, I kinda wish I-DEAS had it, too. Still, I've found a variety of useful things to do with the provided triggers. For example, after an update, I run a program that flags any dimensions that have changed value or become disassociated (broken). After Getting a drawing onto the screen, I run a program that detects certain conditions, and if found, prompts the user to address them. For example, old imported AutoCAD drawings cause some problems with our print routines, so I created a program that cleans them up. I came up with some logic to determine if a drawing is imported AutoCAD, and made that trigger every time a drawing is brought to the screen. If detected, the user is prompted to run the cleaner program.

That last example again highlights the tough choice between running a macro automatically and making a user run it manually. I don't want imported AutoCAD drawings running through my workflows, so on the one hand if I can automatically clean them up that's a good thing. However, in certain rare circumstance, the results of the cleaner are unacceptable. You don't want to be in a situation where your macro causes problems, and if the results are bad, that's a problem.

The approach I use is to only run inconsequential stuff automatically, and try to bring problems to the user's attention automatically, but let anything that might be even the slightest bit destructive be run manually by the user. Then I hammer into the users that when they run macros, if they don't like the results, DON'T SAVE. Ctrl-Z back to where you started, and try again without the macro. If a dimension changes color because my macro told it to, that's not a big deal, that can run automatically. If an entire view disappears, that's a big deal, that should run manually (and maybe not at all!). Automatically detect the imported AutoCAD drawing, but then require the user to run the cleaner manually (albeit presenting a handy way to do so).

With great power, comes great responsibility. The same macros that can really improve someone's workflow can also really ruin their day if they produce the wrong result, or run at the wrong time. You generally don't get too many 'thanks,' but you definitely get the heat if your macro causes problems. Be careful with what the macro does, and think it through before making it run automatically.

No comments: