Lisp with LT: why does (setenv "acad") but not (getenv "acad")?

[Buzz0m]

Hi,
I'm wondering if there are any experts that might tell me (and confirm) why it appears that (setenv "acad") but not (getenv "acad") works in LT? I have a lisp, that sets a certain set of support paths and it works flawlessly in full ACAD and C3D. For some reason I am not able to access the "acad" variable in LT, but I am able to set it?

Can somebody advise on this?

Can somebody confirm their LT (2024/2025/2026) behaves the same way?

This screenshot is taken from my LT2026 session

This is the help file:
https://help.autodesk.com/view/ACDLT/2024/ENU/?guid=GUID-0796D4FE-C07B-4DB6-9C01-9D772CAFA2C0

[-didier-]

Bonjour @Buzz0m 

Can somebody confirm their LT (2024/2025/2026) behaves the same way?

On the 2024LT this line return a list of paths.

I don't have any other version to test, sorry.

Amicalement

[pendean]

@Buzz0m LT limitation for like forever now.

AutoCAD LT did not have or use lisp for the longest time, so Autodesk added a few controls (GETENV, SETENV, etc.) to allow macros to work while pulling environment variables.  Full AutoCAD has lisp/vlisp and has no need for the extra functions as they are accessed via lisp  (getvar... and (setvar... and MANY more tools.  Full AutoCAD is not the same as LT here.

LT tip: instead of SETENV, use (setvar "dimscale" 96), then instead of GETENV use (getvar "dimscale") to set the insertion scale. The parens are required.

From LT's HELP (applies to 2024 through 2026, and well, and LT 2023 all the way back to LTv1 or was in LT95))

https://help.autodesk.com/view/ACDLT/2024/ENU/?guid=GUID-E5F2EB84-5BD8-4A27-A292-5AFFA0214F7B

https://help.autodesk.com/view/ACDLT/2024/ENU/?guid=GUID-79B99ACB-EFDE-431B-A3CC-1131816AEF32 

@-didier- 

[Buzz0m]

@-didier-thanks for the confirmation!

@pendeanI was very surprised a few years ago when LT got limited support for lisp. I quickly found out that many good lisp weren't functioning so I'm not expecting everything to work. What now is causing me a headache is that

1. I tested LT2024 and in that installation (getenv "ACAD") return a list of support paths, just as it should.
2. I tested again on LT2026 on my PC  and (getenv "ACAD") returns "nil"
3. A colleague of mine tested on his LT2024 and did NOT get a list but only "nil

It seems as the ACAD environment variable has not been set on some installations in the registry. How can this be? Where are the support paths stored?

I searched the registry editor and was able to find on my PC the registry entry for LT2024 but not for LT2026. I even tried adding a specific path to the support path in LT2026 but I was unable to find the value of the path in the registry (i.e. I tested if they values of the support paths are stored in the registry at all).

Can somebody explain where the support paths are stored?
Would it be "%appdata%\Autodesk\AutoCAD LT 2026\R32\enu\Support\Profiles\Unnamed Profile"?

[Buzz0m]

ok yeah it's not in the .aws 😄

[Buzz0m]

ok this is weird. It seems that LT2026 is storing the data on my PC in a registry key called "support" and not "ACAD". Is this standard behavior? Is there documentation about this?

[pendean]

@Buzz0m No one here is Autodesk, sorry.

[Sea-Haven · Accepted solution]

You can get maybe LT ? the current support path and change it then Autocad will reset the registry. This has an example of adding to support paths. This is part of a set up CAD say when you do upgrades. Copy and paste 1st line it should return #<VLA-OBJECT IAcadPreferencesFiles xxxxxxx if it returns nil or error rest will not work.

(setq *files*  (vla-get-files  (vla-get-preferences (vlax-get-Acad-object))))
; savepath
;(vla-get-AutoSavepath *files*)
(vla-put-AutoSavepath *files* "C:\\AcadTemp")

; custom icons
;(vla-get-CustomIconPath *files*))
(vla-put-CustomIconPath *files* "L:\\Autodesk\\ICONS")

; custom menu
;(vla-get-Menufile *files*))
;(vla-put-Menufile  *files* "C:\\Users\\2013xxx")

; printers config
;(vla-get-PrinterConfigPath *files*)
(vla-put-PrinterConfigPath *files* "L:\\AutoDESK\\Plotting\\Plot Styles 2011")

; printers style sheet
;(vla-get-PrinterStyleSheetPath *files*)
(vla-put-PrinterStyleSheetPath *files* "L:\\AutoDESK\\Plotting\\Plot Styles")

; printer drv's
;(vla-get-PrinterDescPath *files*)
(vla-put-PrinterDescPath *files* "L:\\AutoDESK\\Plotting\\Drv")

; print spooler
;(vla-get-PrintSpoolerPath *files*)
(vla-put-PrintSpoolerPath *files* "C:\\AcadTemp\\")

; template  path
;(vla-get-TemplateDwgPath *files*)
(vla-put-TemplateDwgPath *files* "L:\\Autodesk\\c3d Templates")

; template location
;(vla-get-QnewTemplateFile *files*)
(vla-put-QnewTemplateFile *files* "L:\\Autodesk\\c3d Templates\\xxxx-2019.dwt")

;make new support paths exist + new
(setq paths (vla-get-SupportPath *files*))
(setq XXXXpaths "L:\\autodesk\\supportfiles;L:\\autodesk\\lisp;L:\\autodesk\\fonts;")
(setq newpath (strcat XXXXpaths paths))
(vla-put-SupportPath *files* newpath)

; Tempdirectory 
;(vla-get-TempFilePath *files*))
(vla-put-TempFilePath *files* "C:\\AcadTemp\\")

;   PlotLogFilePath = "C:\\Documents and Settings\\YYYY.XXXX-AD\\localsettings\\application data\\autodesk\\c3d 2011\\enu\\"
(vla-put-PlotLogFilePath *files* "C:\\AcadTemp\\")

;   LogFilePath = "C:\\Documents and Settings\\YYYY.XXXX-AD\\localsettings\\application data\\autodesk\\c3d 2011\\enu\\"
(vla-put-LogFilePath *files* "C:\\AcadTemp\\")


; xref temp path
;(vla-get-TempXrefPath *files*))
(vla-put-TempXrefPath *files* "C:\\AcadTemp\\")

; end use of *files*

[Buzz0m]

I'm aware that the helpful souls here are all doing it out of love for the game 🙂 

[Buzz0m]

@Sea-Havenyour code helped me solve this. Turns out my lisp already had the correct code in respect for LT. The code terminated due to another issue which was just due to bad practice on my behalf (*facepalm*). I had basically forgotten to wrap a piece of code ment for ACAD in a IF clause and this was causing the error.

The solution is in sea-Haven's example on the lines #38-42 ~
GET: (setq supportPaths (vlax-get-property files 'SupportPath))

SET: (vlax-put-property files 'SupportPath [add string here])

What still perplexes me is that why some LT user seem to have the env variable "ACAD" on LT and some don't. If all user would have that variable I wouldn't have to make custom solutions for LT.

Nevertheless my issue is solved but any insight on the previous statement is appreciated.

[Buzz0m]

As additional info for anybody investigating the env variable "ACAD" on LT:
The users who have the "acad" variable in our company have a mixed set of Autocad products (acad, Lt, C3D) installed. I couldn't pinpoint any specific behaviour as eg. that somebody who has full ACAD as well would somehow get the "acad" variable.

The path to the ACAD variable on my LT2024 is this:

The respective location for LT2026 looks like this

[vladimir_michl]

Yes, LT 2026 behaves differently, indeed. The problem is not in the LISP function (getenv), as the _GETENV command behaves the same - the problem is the missing env. variable. Sounds like a bug to me.

Vladimir Michl, www.arkance.world  -  www.cadforum.cz

[Buzz0m]

The more I look into this the more I fear that the reason some users have the "ACAD" variable in their LT registry has to do with when we were testing the new Lisp functionality in LT when it came back in the 2024 version. The users probably tried to use the functionality which worked for full autocad and when doing this the code they tested probably created the variable which is of no use really for LT itself and was never even created by the software itself or defined during installation. This is my hunch atm and I feel the need to emphasize it so that nobody suspects or tries to find a bug which is just due to bad testing practices on my behalf 😥

[Sea-Haven]

Just a comment, when adding support paths you should first check is path already there use wcmatch. Same for adding custom mnu's/cui/cuix check is it loaded already if so unload it and load new one.