AutoLISP programs commonly require very few changes in order to run on the latest release.
However, an AutoLISP program might no longer run correctly on the latest release because an AutoLISP function, or AutoCAD-based product command or system variable has been changed or deprecated.
General Information
- Obsolete Commands and System Variables
-
Review your custom programs for commands and system variables that have been designated as obsolete. In some cases, an obsolete command or system variable can still be used by your custom programs even though it cannot be entered directly at the Command prompt or accessed from the user interface.
Note: Even though an obsolete command or system variable might still work for a custom program, there is no guarantee that it will continue to work in a future release of the product. It is recommended to rewrite your custom programs to avoid the use of any obsolete commands or system variables.The following techniques might be useful in trying to use an obsolete command or system variable in a custom program:
- Prefix a command name with a period. For example, .BLIPMODE allows for the use of the BLIPMODE command.
- Avoid executing an obsolete system variable with the COMMAND function which might result in an Unknown Command error message; instead, use the GETVAR and SETVAR functions. For example, (getvar "BLIPMODE") returns the current value of the BLIPMODE system variable.
Note: Commands and system variables that have been removed from the product cannot be restored using the previously mentioned techniques.
AutoCAD 2021-Based Products and Later
- Unicode Support
-
The AutoLISP environment has been updated to support Unicode characters which affects functions that are used to manipulate or that return string values. For more information on which functions have been updated for Unicode support, see What's New or Changed with AutoLISP.
Based on the functions used in your programs, changes might be needed for them to handle Unicode characters. For example, the return value of the ASCII function can now be greater than 255 or be different when a Unicode character is passed to the function in comparison to earlier releases. You can use the LISPSYS system variable to identify and control the default AutoLISP environment that is loaded into the program; 0 and 2 = MBCS support (Legacy environment) and 1 = Unicode support.
The following code snippet shows how to determine which AutoLISP environment is currently loaded into the program, and control code execution based on the loaded environment:
(if (= (getvar "LISPSYS") 1) (alert (strcat "Unicode support enabled" "\n(ASCII \"€\") returns 8364" ) ) (alert (strcat "MBCS (Legacy) support enabled" "\n(ASCII \"€\") returns 128" ) ) )
Note: When compiling AutoLISP source (LSP) files with the Visual LISP Integrated Development Environment (VL IDE) or MAKELISPAPP command, the current value of the LISPSYS system variable controls the format in which files are compiled. Files compiled with LISPSYS set to a value of 1, Unicode format, cannot be loaded into AutoCAD 2020 and earlier based releases. Set LISPSYS to a value of 0 or 2 before compiling files to ensure they can also be loaded in earlier releases, but doing this will limit Unicode support.
AutoCAD 2020-Based Products and Later
- INSERT Command
-
The INSERT command now displays the Blocks palette, while the new CLASSICINSERT command displays the "legacy" Insert dialog box. If your AutoLISP program relies on the use of the Insert dialog box, you will need to change your existing program. Previously, you might have used the following AutoLISP statements to display the Insert dialog box:
(initdia) (command "insert")
To continue displaying the Insert dialog box with your AutoLISP programs, you will need to change your existing programs to utilize one of these approaches:
-
(initcommandversion 2) (initdia) (command "insert")
-
(command "classicinsert")
-
AutoCAD 2019-Based Products and Later
- LOCALE System Variable
-
The LOCALE system variable now returns a code that contains a two or more-letter abbreviation which represents the current language rather than a three-letter abbreviation that represented language and sublanguage. The two or more-letter abbreviation is based on the Windows GetLocaleInfo function using the LOCALE_SISO639LANGNAME constant.
Prior to AutoCAD 2019-based products, the code was a three-letter abbreviation returned by the Windows GetLocaleInfo function using the LOCALE_SABBREVLANGNAME constant. The three-letter abbreviation was based on two pieces of information; a two-letter language abbreviation along with a third letter that indicated sublanguage. For example, ENU represented a combination of English language (EN) and United States (U) as the sublanguage.
AutoCAD 2017-Based Products and Later
- CDATE, DATE, and other Date\Time Related System Variables
-
Values stored in the CDATE and DATE system variables no longer represent the current date\time down to the nearest millisecond or one-hundredth of a second. Seconds are now the smallest unit of time in which the values of these two system variables are expressed. If you need to track time intervals smaller than one second, consider using the value returned by the MILLISECS system variable which stores the difference in time since the workstation was booted in milliseconds.
The following date\time related system variables were also affected by the removal of milliseconds:
- TDCREATE
- TDINDWG
- TDUCREATE
- TDUPDATE
- TDUSRTIMER
- TDUUPDATE
If any of your existing programs require time differences down to the nearest millisecond, you could obtain the last 2 or 3 digits of the value stored in the MILLISECS system variable and append them to the value returned by the CDATE system variable which would produce a value comparable to that returned by the CDATE system variable in AutoCAD 2016-based products and earlier. The following code sample shows how you might go about getting a date\time value that includes milliseconds based on the target AutoCAD release:
; Returns a CDATE value that includes milliseconds based on release ; Usage: (CDate) ; Replaces (rtos (getvar "CDATE") 2 8) (defun CDate ( / ms) ; Check to see which AutoCAD release is being used (if (<= (atof (getvar "ACADVER")) 22.0) (rtos (getvar "CDATE") 2 8) (progn ; Get the current milliseconds and append it to the CDATE value (setq ms (itoa (getvar "MILLISECS"))) (strcat (rtos (getvar "CDATE") 2 6)(substr ms (- (strlen ms) 2))) ) ) )
- EPDFSHX System Variable
-
The EPDFSHX system variable introduced with AutoCAD 2016 Update 1 has been renamed to PDFSHX. As a result of the name change, any AutoLISP statements that reference the EPDFSHX system variable must be revised. These are the functions to most likely be impacted by this change in your custom programs:
- GETVAR - A nil value will be returned rather than an integer value of 0 or 1
- SETVAR - Execution of the program might be halted and the error message ; error: AutoCAD variable setting rejected: "epdfshx" will be produced
- COMMAND - Execution of the program might be halted and the error message EPDFSHX Unknown command "EPDFSHX" will be produced
AutoCAD 2016-Based Products and Later
- Digitally Signed Files
-
AutoLISP files can now be digitally signed. Digitally signing an AutoLISP file allows it to be loaded into the AutoCAD drawing environment without warning the user that the file isn't trusted. VLX files that are digitally signed cannot be loaded into AutoCAD 2015-based or earlier products.
- osnap Function
-
The osnap function no longer supports the Quick (qui) Object Snap mode. References to the qui mode must be removed from all statements that use the osnap function in your AutoLISP programs. If the mode is not removed, the osnap function returns nil instead of a coordinate value for a valid point in the drawing area.