Trim Command with LISP 2005 vs 2009

[Bill Tillman]

The automation codes I've written over the past months are deployed and the users are screaming about all the bugs. Some of the bugs are real bugs, but most of the complaints so far are personal preferences which the users want. Since we're about to go ISO 9001 compliant I don't think personal preferences are going to last around here. But there is one issue which is causing me some concern.

This automated process creates a somewhat complex drawing, three orthographic views of an assembly. The assemblies can be anywhere from the size of a bread box to the size of a small truck...and everything in between. The code inserts lines and blocks of all kinds and there is need for trimming many lines before the process completes. What I have started to notice is that all the 2009 users are remaining quiet about the trimming. But the 2005 users are complaining and when I check the drawings created with 2005, the trimming functions are not working at all. This is very strange indeed. I run 2012 at my home and it's fine with the codes, but the older 2005 version seems to ignore all the trim operations. The users are all running the exact same code, in fact they all are running the exact same files from the central server.

I would not have expected this behavior from 2005 vs 2009.

[Lee Mac]

This is one of the major issues with using command calls in applications (i.e. calling standard AutoCAD commands), apart from being slower, there are many compatibility issues arising when the program is used in various versions of AutoCAD. The most obvious is the prompt order for some commands is subject to change between versions, but other subtle differences in the command behaviour can also be apparent (the Fillet command is one example that springs to mind).

However, since your program is generating all of the geometry anyway, and not working with existing user-generated geometry, why not generate precisely the required geometry and avoid the need to trim?

[irneb]

I'm assuming you're using fence selection for trimming. I can't remember when this became available, but it might be somewhere around 2005. Perhaps that's why it's not working.

I'd add my vote to Lee's comment: Try to use entmake/entmod/ActiveX as much as possible instead of command-lines. Not so much "speed", but compatibility between versions is a lot greater. It would also alleviate the other problem you have about zoom level interference.

[Bill Tillman]

Thanks for the replies. My code makes use of entmake whenever possible and I have a few other vlax commands when doing text overrides on some dimensions. But this is a tricky drawing in that each time it's drawn, the sizes are different. And there are intermediate support ribs which have on center spaces which are never the same from one drawing to another. Here is an example of one of the trim code algorithims I came up with:

(setq count 1)
      (while (<= count numribs)
       (command "._TRIM"
         (polar (polar pt7 (dtr 270.0) 1) (dtr 0.0) (- b 3))
         (polar (polar pt7 (dtr 270.0) 2) (dtr 0.0) 3) ""
         (polar (polar pt7 (dtr 270.0) (+ cvrplthk 0.1875)) (dtr 0.0) (- (- b 1.5 rbandthk (* riboc count) 0.0625) (* ribthk (- count 1))))
         (polar (polar pt7 (dtr 270.0) (+ cvrplthk 0.0625 (- ribht 0.0625))) (dtr 0.0) (- (- b 1.5 rbandthk (* riboc count) 0.125) (* ribthk (- count 1))))
         "")
       (setq count (+ 1 count))
    ); end while

As you can see, the geometry is all done on the fly. And this make the trimming processes I'm using necessary. I don't know that this kind of trimming could be done any other way. The ribs are spaced evenly across the span and then the solid lines which were drawn in for the frame must be trimmed inside all the rectangles which were drawn as the ribs.

I setup a small test last night on one of the 2005 workstations. I drew three circles, then drew a long line through the centers of all of the circles. Then using a non-fence trim method I was able to trim the lines correctly. Today I will try and do some more tests using the fence method on 2005 systems.

[Lee Mac]

Another option might be to use the IntersectWith method to determine points of intersection between your objects; then, instead of trimming the objects, you could construct the necessary arcs / lines between the intersection points, erasing the original objects.

[Bill Tillman]

OK, it's now been proven beyond all doubt...or maybe not!

(defun c:test1 ()
  (vl-load-com)
  (setvar "osmode" 0)

(setq pt1 '(10.0 10.0))
(setq pt2 '(12.0 20.0))
(command "._RECTANGLE" pt1 pt2)
(setq pt1 '(20.0 10.0))
(setq pt2 '(22.0 20.0))
(command "._RECTANGLE" pt1 pt2)
(setq pt1 '(30.0 10.0))
(setq pt2 '(32.0 20.0))
(command "._RECTANGLE" pt1 pt2)

(command "._LINE" '(7.0 15.0) '(35.0 15.0) "")
(command "._TRIM" '(33.0 17.0) '(7.0 12.0) ""
          '(31.5 19.5) '(30.5 10.5)
           '(21.5 19.5) '(20.5 10.5)
           '(11.5 19.5) '(10.5 10.5) "")
  
(princ)  
); end function

Load and run this code in AutoCAD 2005 and it will not trim the horizontal line within the rectangles. But in 2009 it will. I cannot say with 100% certainty at this time that there is still not some different environment variable that all the 2005 users have vs the 2009 users. But this code will work in 2009 and not in 2005. It appears that with 2005 you can fence around/thru the trimming (cutting) objects, but you cannot fence around/thru the objects to be trimmed.

The only reason I am reserving full confirmation on this is that this shop represented itself to me as a standard compliant entity when I first signed on in early January. Now, having worked with all the individual users and their desktops it has become abundantly clear that all these user's comply with standards. It's just that each and every one of them have their own standards. One lady's right mouse button does something completely different than the next guy's. I know they think they are following standards but it's not quite there just yet.

[irneb]

That's because the "automatic" fencing (or rather select by crossing) for trim, was introduced somewhere after 2005 (I think 2008 ).

Try adding the "_Cross" modifier into the trim command in 2005. Sorry, I don't have 2005 anymore for testing. Can't remember if such could work, or if you needed to pick each entity in turn (like the old "Remove objects from the stretch command did).

Otherwise you could do a hybrid of what Lee suggested: Select by crossing using those points, obtain the ename & crossing point using ssnamex. For each in that selection set, send an entity pick point (build using the ename & point as you'd get from entsel) to the trim command.

Although in your example, I'd go with Lee's idea in full. Perhaps your example is too simplistic in comparison to your real-world cases.

[Bill Tillman]

Thanks again for the insightful advice. I tried the _Cross modifier but no luck with it. And yes, the drawings I'm preparing with this code are far more complex than I can show here. I'm under confidentiality agreements and I have to be very careful with what I post in public places.