Community
@NirantarVidyarthee wrote:It is recommended that you should avoid using (command) functions in AutoLISP.
But it seems that trim and fillet / chamfer are three tasks for which using the (command) function is the only viable alternative. (even com methods are not available for them).
I would like to here what you all think about it.
I've never agreed with that "should avoid" philosophy. Yes, there are circumstances in which you can't use (command) [e.g. in a reactor], and others in which you can save a detectable amount of time using other methods [e.g. drawing comparatively large numbers of things], so you should be aware of situations where it's worth considering which approach to use. But most of the time, (command) works fine, and it very often lets you do something with a lot less code. I think of the (command) [or (vl-cmdf) if you prefer] function as essentially a sub-routine -- in many cases it will figure out a heck of a lot of stuff for you, so you don't have to, and I'm glad to take advantage of that. Another way to think of it: the (command) function is included in AutoLISP for a reason [i.e. if it were something one should avoid, maybe it wouldn't be there].
Yes, as devitg says, you can probably duplicate what Fillet and Trim and Extend do with things like (subst)/(entmod) and (entmake) and some (vla...) functions. And in the case of, for example, Filleting two Lines with a zero radius, that's not too complicated [though you do need to figure out not only their intersection point, but also which end of each Line to change, based on the intersection or apparent intersection and its relationship to both the pick points and the direction in which the Lines were drawn]. But imagine the calculating shenanigans you would have to go through to do something as dead-simple for (command) to do as a non-zero-radius Fillet on two Arcs -- finding the location of the center of the new Arc, and its starting and ending angles, and figuring out which end of each of the existing Arcs to change, and their new starting or ending angles, affected by whether the two existing Arcs curve in the same or opposite directions, etc., etc.
But plenty of other commands besides those, that could be replicated using (entmake) etc., can also be hugely easier using (command). Consider, for example, a polar Array of a possibly multi-object User selection that might include various different kinds of entities. It would be complicated enough to work out how to calculate all the instances of just one type of object around the array, and then you'd need to come up with a completely different set of calculations for every different entity type that a User might select in using the routine.
For an extreme example of something that (command) does more easily, look at this thread. If you choose to try it out, get the version of InsulBattPoly.lsp from Message 11 [or from here], but whether you do or not, look at the image attached to Message 2. In the lower right corner is a fun possibility that you'd never actually do, labeled (IB Squared!). It's the result of using the IB routine to make a Polyline representation of a short stretch of Insulation Batting based on an initial straight Line, and then using it again on the result of that, making a Polyline that represents insulation running along a route that's the shape of insulation squiggling. As I recall, that Polyline has something over 1,700 vertices, with multiple arc segments mixed with line segments in each loop, and very subtly varying bulge factors on arc segments as the path swings around through varying degrees of curvature. It's complicated enough to get the IB routine to do that using (command), as you'll see if you open up the .lsp file, but I defy anyone to accomplish something like that using (entmake).
There are also certain System Variables that are read-only [e.g.UCSORG], so that you can't change them using (setvar), but the way you do so is with the appropriate command.
Kent Cooper, AIA 
@NirantarVidyarthee wrote:It is recommended that you should avoid using (command) functions in AutoLISP.
But it seems that trim and fillet / chamfer are three tasks for which using the (command) function is the only viable alternative. (even com methods are not available for them).
I would like to here what you all think about it.
Its not that you have to "avoid" a call to command, some task is loads easier and better using native commands as long as you provide the necessary error checking. perhaps vl-cmdf would be more appropriate as devitg and kent suggested.
There are instances that using command wont cut it, like processing objects thru multiple layouts as the layout needs to be active on runtime where the objects is located when using command fucntions. sure you can use (setvar 'ctab layoutname) but would you really want to do that with like 20 layout tabs?
Anyhoo, What do you have in mind?
@sanganaksakha wrote:I have faced problems with programs that use (command) function when migrating to higher versions because of changes to syntax etc. Hence, I prefer not to use (command) function.
But in case of fillet / chamfer, I thought that it would not be worth the efforts to write an alternative function. I just wanted confitmation for this.
Thanks to all.
True in most cases, however, you can use initcommandversion to force version compatibility.
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")
