LISP file does not work on 2024/2025 AutoCAD LT

[tpottebaum]

Hello, I have been trying to develop a simple LISP code to run on AutoCAD LT 2025. I originally went to chat GPT to get a solid starting point as I haven't practiced coding in a while. Since then I have been modifying the code (I thought unsuccessfully).

To give some insight on the code, it's essential function is to fill a selected rectangular outline with 4'x'8 rectangles. The outline I've been using for this is a 10'x34' rectangle. In this code, it would start in the bottom left corner and use a while loop to create vertical 4x8 rectangles, then fill in the remaining length with a skinnier 8' tall rectangle (a 2'x8' in my case). The code then essentially repeated the process for the remaining area above, except with horizontal rectangles, then finally filled in the top right hand corner. 

The first part of the code was working great, but whenever it got to the remaining area on the right, it would place a 2'x10'. I could not for the life of me figure out why this was happening. Eventually simplified my code down to the initial while loop, and I just hardcoded a rectangle command with the exact coordinates for that rectangle's location, and still I got a 10' tall rectangle. So I sent this code to a coworkers computer (he was using AutoCAD 2024) and it worked. I then tried my initial code to fill in the entire area and that also worked perfect. 

I've been working with an Autodesk Directly expert and he is also stumped. I sent him my AutoCAD file and he had the same issue I had, but when he recreated it in 2024 he did not. I tried it on my end with 2024 and I still had the issue. Attached is the test code I have been running. With this code, if I make my 10'x34' rectangle in the location such that the hardcoded rectangle will get placed in the correct spot, it will generate a rectangle in the right spot, but it's 2' taller than what is hardcoded in. If I move that outline somewhere else, the hardcoded rectangle will drop in exactly how it's hardcoded. 

Has anyone experienced something like this?

*Update to this question* 

The Autodesk Directly expert used this link to the starting file I was using. This will have the rectangle I was using. If you use this link and run the code attached, you should see the same thing I have been seeing, unless you are on 2024, then it may work?

https://autode.sk/3KQw1aG

[paullimapa]

I ran your code on full version of 2024 & 2025 and both have same results:

[paullimapa]

interestingly enough when I created the big rectangle in the position where the thinner rectangle would go then it worked on both 2024 & 2025...and I didn't have any running object snaps set.

[tpottebaum]

This is the link to my AutoCAD file that I was using for this. If I remember correctly the expert I was working with had the same issues I had when using it and could not figure out why. I forgot to add this in to the initial question.

The 10'x34' should be horizontal, I believe in this link it should have it placed in the location where the hardcoded rectangle will start in the correct spot.

https://autode.sk/3KQw1aG

[paullimapa]

both results are same in 2024 & 2025

[pendean]

Did you watch, in detail, to what your colleague did in 2024?
Perhaps something as simple as they did NOT have running osnaps... .

I would sit with them and do a deep dive into all of their settings. Then mimic.

[tpottebaum]

It looks like your white rectangle wasn't in the correct spot given it's bottom edge isn't lining up with the last blue rectangle. Be sure that the bottom left coordinate is set to 14', 12', then the white rectangle is 10'x34'. If this is true, then the hardcoded rectangle in the code will (theoretically) line up in the right spot, to match the pattern of the other rectangles. In this specific scenario I was seeing the hardcoded rectangle have incorrect coordinates (as was the Autodesk direct expert).

I say this because what you're seeing is the result I was seeing when that main rectangle was placed elsewhere, but when I put it in that exact spot the hardcoded rectangle behaves differently. If you also use the link to my AutoCAD file that I have in my original post, I think you will see a different result. 

[tpottebaum]

Yes all of the required settings are the same. I was the one who ran the code on the other machine so I can verify the exact same process was used as well. I spent a lot of time with an Autodesk directly expert and he was unable to figure out what was going on. When using the AutoCAD link I have in my original post, given the rectangle is 10'x34' with a bottom left coordinate of 14', 12', the last blue rectangle comes incorrect even though it is a hardcoded rectangle. This appears to only happen when using a file originating from my machine. All settings were reset to default and still the same result. 

[paullimapa]

I did use the link so this is your drawing file that I ran the code in for both 2024 and 2025 which ended with the same result as I posted. 

[tpottebaum]

Interesting. The Autodesk directly expert was able to get the result I was getting. This is a picture of what I get after running that code, given my white rectangle is in the correct spot. As you can see, the last blue rectangle should be the same height as the others, but here it is 10' tall. If I move my white rectangle 5' to the left, then the second picture is my result. The last rectangle is placed at the correct 8' height. Nothing changed here besides the coordinates of my white rectangle.

[Kent1Cooper]

Can't you just use a Hatch pattern?  That would be a simple two-line pattern definition.  Assuming your drawing unit is an inch:

*4by8
0, 0,0, 0,96
90, 0,0, 0,48

If it's a foot, change the 96 to 8 and the 48 to 4.

Then you can do it in any shape boundary -- it doesn't need to be rectangular.  [And it certainly doesn't need to be positioned in exactly the right place -- how useful is that?]  The Hatch ribbon will let you set the pattern origin at the lower left corner if you always want it as described, or anywhere else that may be better in a given situation.  Or you can set HPORIGIN there before Hatching.  And of course you have all the other Hatching options, such as non-zero rotation if you want, etc.

It did these in your 10' x 34' rectangle:

 

[paullimapa]

time to examine the code and see how it executes in the dwg line by line to see the cause of this odd result

[tpottebaum]

I had not thought of that, yes I think it would work pretty well. The only issue being in the future I'd like to modify the code to account for some weird cases that I have. The issue here is not my code. I have a basic version created that has run successfully on another machine, but not on mine. This is why I created a simplified version to test with a hardcoded rectangle, and even that doesn't work. 

[tpottebaum]

I haven't found anything out of the ordinary with the code, it is pretty straightforward. I don't have a clue what could be causing this

[Kent1Cooper]

It seems pretty obvious to me -- in test7.lsp, the remaining-on-the-right rectangle is defined by absolute coordinates, rather than in relation to what it's been doing.  Change this:

(command "RECTANGLE" (list 552.0 144.0) (list 576.0 240.0 ))

to something like this [untested]:

(command "RECTANGLE" (list currentX currentY) (list maxx (+ currentY rectHeight)))

[and of course with OSNAP not running].

ChatGPT is part of your problem -- it simply isn't good enough at AutoLisp yet.  It has led you astray in other ways, for example changing back to Layer 0 at the end doesn't do that [it should be the "_set" option, not the "_on" option].  And the "foam" Layer will be turned on by the "_make" option if it already exists but is off, so the "_on" option with that Layer is pointless, although "_thaw"ing it first could be advisable [it will have trouble if it exists but is frozen].

[tpottebaum]

The reason I have it defined by absolute coordinates is to make obvious the issue I'm having. In my code, everything works fine except for a simple rectangle command with hardcoded coordinates. Do you know of any reason this would happen? I have absolute coordinates for a 2'x8' rectangle, and it spits out a 2'x10'. This doesn't make any sense to me. 

[Kent1Cooper · Accepted solution]

Running object snap modes including ENDpoint among them would perfectly explain the difference between the images in Message 10.  That has already been suggested as a cause -- have you tried with running Osnap off?  Or, force it to ignore that for that second point [or for both, but the first one will Snap to where you want it anyway]:

(command "RECTANGLE" (list 552.0 144.0) "_non" (list 576.0 240.0 ))

[tpottebaum]

You're exactly right. I naively overlooked that suggestion initially. I never would have thought that would affect that command in my code. Turning off endpoint osnap solves all my problems. 

[paullimapa]

You must have missed what I wrote in my reply in msg 3:

”.and I didn't have any running object snaps set.”

[tpottebaum]

Yes I did miss that. Looks like that was suggested multiple times. It seemed very trivial to me at first, my own naivety getting in the way... Thank you all for the help.