by Fenton Webb
By now, if you have been following my posts, will have probably realized that I really do like acedCmd and acedCommand (command in LISP).
I wanted to write an tell you how you should format the command strings and keywords that you pass to these functions,
Firstly, let’s talk about the Command strings themselves. AutoCAD comes in many languages, and the Command strings are actually translated for each language. This means that we can never assume the English LINE command will be called the same in the Russian version, for instance. As a programmer, one that uses acedCmd or acedCommand, we don’t really want to worry ourselves about localized Command strings. Thankfully, we can always access the English (non-localized version of any Command string by using the underscore symbol… e.g.
Another issue that programmers like us don’t want to worry ourselves with when using acedCmd or acedCommand is whether or not the user has REDEFINE’d one of the Commands that we want to use… If they have, they could cause our lovely program to fail because they have changed the way the command we are using works – costing us support calls!! Thankfully, we can always access the raw Command using …. e.g.
You can combine both of these tricks together… e.g.
in roundup, the “correct” way to specify Command Strings using acedCmd and acedCommand is: prefix all Commands with _.
Finally, let’s talk about the keyword strings that you pass to acedCmd or acedCommand. Again, these are localized, again we don’t want to worry about running into keywords that are different on different localized versions of AutoCAD, so we can use the underscore technique... (note you cannot REDEFINE keywords, so there is no dot required)… e.g.
You’ll notice that I have specified the whole keyword string, not just _S. Why I recommend that you do this is is purely from experience…
1) Commands can change in the future, if you specify _S then later on, we introduce a new keyword called _Separate, then your code is broken. Always use the full keyword, it will save you time and effort in the future.
2) It’s easier to read in your code… You’ll be glad of this years down the line when you are trying to remember what the command is doing.