« February 2017 | Main | April 2017 »

What's New In the AutoCAD 2018 APIs and Developer Documentation

AutoCAD 2018 marks for me the 11th product release that I worked on, it is hard to believe that I started working with the AutoCAD team about 12 years ago now (2 years as a consultant and going on 10 years as an employee). Prior to joining Autodesk, I was a developer for a fairly large company and an ADN member that lived and died by the AutoCAD developer documentation.  For me, this release marks a special milestone that I have been pushing towards for several years now and that is the merging of the AutoCAD platform developer documentation.

The AutoCAD application programming interfaces (APIs) this release has seen some changes, based on your usage of certain areas the changes might feel minor while to others they might be major. In this article, I simply highlight the changes that were introduced and don't go into any great depth; you can find out specifics about the API changes in the developer documentation itself.  I do plan on covering some specific changes in future articles though.

The AutoCAD developer documentation can be found at:
http://help.autodesk.com/view/OARX/2018/ENU/

Some of the developer documentation (AutoLISP and ActiveX), can also be found while searching in the AutoCAD product documentation:
http://help.autodesk.com/view/ACD/2018/ENU/

The following outlines the changes that were made to the AutoCAD APIs:

General Updates

  • Developer Documentation Home Page has been expanded and slightly reorganized:
    • AutoLISP and DCL related links are now broken out into their own subsections
    • Documentation for the non-standard AutoCAD ActiveX libraries has been broken out into their own subsection
    • Managed .NET Reference guide is now merged into the online documentation
    • ObjectARX documentation has now been merged into the online documentation
  • Updated the HEADER Section of the DXF documentation to include the AC1032 value for the AutoCAD 2018 drawing format of the $ACADVER variable
  • Documentation was centralized and a table of contents (TOC) was reintroduced for all publications

AutoLISP

DCL

  • No new or changed functions/tiles this release.

ActiveX/COM

  • No new classes were added, but the ProgIds for the following have changed which might impact your existing programs:
    • AcadAcCmColor
    • AcadApplication
    • AcadLayerStateManager
    • AcadSecurityParams
  • The IAcadFileDependencies and IAcadFileDependency classes are now obsolete as a result of the File Dependency feature being removed
  • The AcSaveAsType enum was updated to include constants for the new drawing file format
  • Documentation continues to be available online through the AutoCAD product help and now the AutoCAD developer documentation site, and offline as CHM files in the %ProgramFiles%\Common Files\Autodesk Shared\en-US\ directory; the two CHM files are named acad_aag.chm and acadauto.chm
  • Historical list of changes from AutoCAD 2000 through AutoCAD 2018 can be used to identify potential problems in existing programs(http://help.autodesk.com/view/OARX/2018/ENU/?guid=GUID-F3522375-9407-48B7-BE25-E24BC07C5F23)

Managed .NET

ObjectARX

JavaScript

Hope you found this overview of the changes to the AutoCAD APIs and developer documentation helpful.

Sincerely,
  Lee

Posted at 04:11 PM in AutoCAD 2018, AutoLISP/Visual LISP, C++, ObjectARX, ObjectARX 2018 SDK, Programming, VB.NET | | Comments (2)

| | | Pin It! | | |

PSA: windows.h is No Longer Implicitly Included with aced.h In the ObjectARX 2018 SDK

Prior to the AutoCAD 2018-based products and the ObjectARX 2018 SDK, the aced.h header file implicitly included <windows.h>. When building ObjectARX applications for AutoCAD 2018-based products on Windows, you must now include <windows.h> in one of your C++ source files when aced.h is included. Failure to do so will result in a series of compiler errors that cause the project to no longer build. The following image shows an example of the compiler errors you may encounter when including aced.h and not windows.h.

Aced_windows_h compiler errors

Sincerely,
  Lee

Posted at 09:28 AM | | Comments (0)

| | | Pin It! | | |

AutoCAD Developer Documentation Survey (Follow-up) - Part 2

Picking up a project that you are passionate about can be very easy, but it can also be a burden at the same time.  I was given the opportunity just over 4 years ago to lead the AutoCAD developer documentation, which for me was very near and dear to me as I was a consumer of the developer documentation for about 10 years prior to joining Autodesk.  Since I had experience with developing custom solutions for AutoCAD and AutoCAD-based products, I had my personal experience to lean on but as we all know everyone's experience is very different. Getting an understanding of how others work and their needs for developer documentation is why the AutoCAD Developer Documentation Survey came into existence.  The most recent survey was conducted in early 2016 (148 responded), and the first one was conducted in early 2013 (405 responded).

For a summary of the results from the most recent AutoCAD Developer Documentation Survey, see AutoCAD Developer Documentation Survey (Follow-up) - Part 1.

The results from those two surveys have helped to shape the developer documentation into what it has become today. The following outlines the many enhancements that have been influenced by the survey responses over the past 4 years along with other improvements made since AutoCAD 2012:

AutoCAD 2018

  • Re-introduced a traditional table of contents for the developer documentation.
  • Centralized all the AutoCAD developer documentation, with the exception of the JavaScript Developer's and Reference Guides, online and in a single location.
  • A CHM version of the Managed .NET Developer's Guide is now part of the ObjectARX SDK.
  • XML documentation for the AutoCAD Managed .NET libraries is now part of the ObjectARX SDK.
  • Remaining Managed .NET related content in the ObjectARX Developer's Guide was moved to and integrated into the Managed .NET Developer's Guide.

AutoCAD 2017

  • Initial release of the XML documentation made available for the AutoCAD Managed .NET libraries; documentation is accessible via tooltips and the Object Browser in Microsoft Visual Studio.  Files were also made available for AutoCAD 2015 and AutoCAD 2016 versions of the Managed .NET libraries.
  • Improved performance of the ObjectARX and Managed .NET Reference topics in the integrated help that can be accessed from within Microsoft Visual Studio 2015.
  • Added short descriptions to the Search results displayed in the Microsoft Help Viewer that is part of Microsoft Visual Studio.
  • A CHM version of the Managed .NET Developer's Guide was made available for download from the AutoCAD Developer Center on Autodesk.com.
  • CUI library documentation was moved from the ObjectARX Developer's Guide to the Managed .NET Developer's Guide.

For more information see, AutoCAD 2017 ObjectARX and Managed .NET Documentation and What's New In the AutoCAD 2017 APIs and Developer Documentation.

AutoCAD 2016

  • Introduction of the CAD Standards Plug-in and Transmittal API reference documentation in the AutoCAD product documentation, previously only available as part of the ObjectARX Reference Guide in the ObjectARX SDK.
  • Improved the content of the Transmittal API reference documentation to include sample code that was previously written for an AU session that never ran.
  • Improved the content of the CAD Standards Plug-in reference documentation to include sample code based on one of my past AU sessions.
  • Introduction of an alphabetical list for DCL tiles and predefined attributes.

For more information see, AutoCAD 2016 Developer Documentation Changes.

AutoCAD 2015

  • Introduction of Developer Documentation Home page in the AutoCAD product documentation.
  • Flat landing pages were introduced for the AutoLISP Developer's and Reference documentation, ActiveX Developer's and Reference documentation, General Customization documentation, and Managed .NET Developer's documentation.
  • AutoLISP Reference documentation was restructured to be platform neutral (cover both Windows and Mac OS) and all function topics were redone for consistency.
  • ActiveX Developer's and Reference Guides added to the AutoCAD product documentation; content was also restructured for consistency.

For more information see, AutoCAD 2015 Developer Documentation Changes.

AutoCAD 2014

  • Introduced a historical listing of AutoLISP function changes that covered AutoCAD 2009 and later.
  • Initial release of the CAD Administration content.
  • ActiveX Developer's and Reference Guides were made available as CHM files via the AutoCAD product installation.
  • Classmap.dwg that ships with the ObjectARX SDK was updated to include the ActiveX inheritance and object map.
  • Updated the samples in the ActiveX Reference Guide and introduced versions of each sample written in AutoLISP in addition to the VBA samples.

For more information, see AutoCAD 2014 API and Developer Documentation Changes and AutoLISP Documentation Updates - Windows and Mac.

AutoCAD 2013

  • ActiveX Developer's and Reference Guides were made available as CHM files once again and could be downloaded from the AutoCAD Developer Center on Autodesk.com.
  • Introduced a historical listing of ActiveX member changes that covered AutoCAD 2000 and later.

AutoCAD 2012

  • Initial release of the ObjectARX and Managed .NET Reference Guides to work with Microsoft Visual Studio 2010.

While many improvements have been made in recent years to the AutoCAD developer documentation, there is still much work to do.  If you have any comments or feedback about the AutoCAD developer documentation, I would like to hear from you.

Sincerely,
  Lee

Posted at 02:51 PM in AutoCAD, AutoCAD based products, Customization, Programming | | Comments (0)

| | | Pin It! | | |

AutoCAD Developer Documentation Survey (Follow-up) - Part 1

The AutoCAD Developer Documentation survey has been posted twice over the past 4 years, but the results of those surveys and how those responses were used hasn't really been shared.  Because we value the input from our communities, I am giving you a glimpse into the survey results and a number of documentation improvements that have been made as a result of the responses in the past few years.  Of course, there is always room for improvements and we hope that you will continue providing us valuable feedback in future surveys. The most recent survey was conducted in early 2016 (148 responded), and the first one was conducted in early 2013 (405 responded).

Link to the original article related to the 2016 survey - AutoCAD Developer Documentation Survey - 2016.

Note: Keep in mind, the information in this posting is based on the voluntary responses of those that create custom solutions which extend the functionally of AutoCAD and AutoCAD-based products; the information doesn't directly represent the user base of those that use AutoCAD or AutoCAD-based products and is in no way representative of where Autodesk is investing in product development.

Assumptions: Those that responded to the survey are most likely developers, CAD administrators, and others that extend the functionality of AutoCAD and AutoCAD-based products.

What Release(s) of AutoCAD Do You Support?

When asked, a majority of the respondents indicated they were targeting the latest 2 releases while a percentage also indicated they support 2 or more previous releases along with the latest release. The following is a summary of the results of the respondents in the most recent survey:

  • AutoCAD 2016 - AutoCAD 2017 (70%+)
  • AutoCAD 2014 - AutoCAD 2015 (55%+)
  • AutoCAD 2012 - AutoCAD 2013 (25%+)

In addition to those AutoCAD releases that respondents identified, the following are the most popular AutoCAD-based vertical products that the respondents identified they were developing for in the most recent survey (items are not listed in any specific order):

  • AutoCAD Architecture
  • AutoCAD Civil 3D
  • AutoCAD Map 3D
  • AutoCAD Mechanical

What Programming Languages Are the Most Popular?

As a developer, there are many different programming languages available and many more seem to be introduced each year.  While there are no endless options available for developing custom applications that can be loaded into AutoCAD or AutoCAD-based products, there are a number of mainstream options available.  Respondents stated these were the top programming languages that they used and their order of importance\usage:

  1. C#
  2. AutoLISP
  3. VB.NET
  4. C++
  5. VBA
  6. JavaScript
  7. F#

Do You Use the Developer Documentation in the ObjectARX SDK or Product?

The AutoCAD developer documentation is delivered as part of the AutoCAD product and ObjectARX SDK.  75+% of all respondents stated that they use the developer documentation that is part of the ObjectARX SDK which makes sense given the number of respondents that use the C#, VB.NET, and C++ programming languages to extend the functionality of AutoCAD and AutoCAD-based products.  The ObjectARX SDK contains these documentation components:

  • ObjectARX Developer's Guide
  • ObjectARX Reference Guide
  • ObjectARX Interoperability Guide
  • ObjectARX Migration Guide
  • ObjectARX Readme
  • Managed .NET Reference Guide

Note: The Managed .NET Developer's Guide was made available as part of the ObjectARX SDK starting with the 2017 release.

The AutoCAD product documentation contains these developer documentation components and they are used by more than 82% of all respondents:

  • General Customization (UI, scripting, Action Recorder, linetypes\shapes\hatch patterns, slides among more)
  • AutoLISP Developer's Guide
  • AutoLISP Reference Guide
  • AutoLISP Tutorials
  • ActiveX Developer's Guide
  • ActiveX Reference Guide
  • Sheet Set Object Reference
  • Transmittal API Reference
  • CAD Standards Plug-in
  • Connectivity Automation Object Reference

The JavaScript Developer's Guide and JavaScript Reference Guide are linked to the AutoCAD product documentation, but not part of the product documentation set.

For the respondents, these were the most commonly accessed/used documentation components and the order of importance:

  • Managed .NET Developer's Guide
  • Managed .NET Reference Guide
  • General Customization Guide
  • AutoLISP Reference Guide
  • ObjectARX Developer's Guide
  • ObjectARX Reference Guide
  • AutoLISP Developer's Guide
  • ActiveX Reference Guide
  • ActiveX Developer's Guide

While a majority of respondents identified that they use the documentation that is part of the product and ObjectARX SDK, 30+% of the respondents identified that they were unaware of these documentation components:

  • Sheet Set Object Reference
  • Transmittal API Reference
  • CAD Standards Plug-in
  • Connectivity Automation Object Reference
  • JavaScript Developer's Guide
  • JavaScript Reference Guide

How Do You Want to Access the Developer Documentation?

Respondents of the survey identified these delivery methods as the most desirable for accessing the developer documentation; methods are listed in the order of importance:

  1. CHM
  2. HTML (via product documentation)
  3. PDF
  4. Microsoft Help (via Microsoft Visual Studio)

88+% of all respondents have expressed interest in being able to access all the developer documentation from a single location online, and that 85+% have access to the Internet while they are authoring programs.

Of those that responded, 33+% of them access the ObjectARX and Managed .NET Reference documentation via the Microsoft Help feature in Microsoft Visual Studio.  However, 35% of the respondents were unaware that the ObjectARX and Managed .NET Reference documentation could be integrated into Microsoft Visual Studio.  Even though there was a vast range in those that knew or didn't know about the documentation integration with Microsoft Visual Studio, many respondents expressed interest in accessing developer documentation from within Visual Studio that wasn't just the ObjectARX and Managed .NET Reference Guides.

The documentation components that respondents want to access from Microsoft Visual Studio and their priority are:

  1. Managed .NET Developer's Guide
  2. ObjectARX Developer's Guide
  3. JavaScript Developer's Guide
  4. ObjectARX Interoperability Guide
  5. JavaScript Reference Guide
  6. ObjectARX Migration Guide
  7. Sheet Set Object Reference
  8. VBA/ActiveX Reference
  9. ObjectARX Readme
  10. VBA/ActiveX Developer’s Guide
  11. CAD Standards Plug-in Reference
  12. Connectivity Automation Object Reference
  13. Transmittal Object Reference

 The responses of both surveys have lead to a number of minor and major improvements to the AutoCAD developer documentation.  I will mention the improvements made in Part 2.

Sincerely,
  Lee

Posted at 05:00 PM in AutoCAD, AutoCAD based products | | Comments (0)

| | | Pin It! | | |

Debugging AutoLISP Programs - Part 2: Basic Debugging

The AutoLISP programming language supports some basic debugging techniques that can be utilized to help troubleshoot problems within a custom program. Displaying messages or values during the execution of a custom program can be beneficial in identifying the statement that is failing during execution. By looking at the last message or value returned, it will give you a basic or exact idea on where to start looking for the problem within the custom program based on the number of messages placed throughout your custom program.

These AutoLISP functions can be helpful in providing basic information in the AutoCAD user interface which can be used to determine where a program might have failed:

  • alert – Displays a message box containing a text message.
    Syntax: (alert message)
  • princ – Displays a value assigned to a variable or returned by an expression, or a text message at the Command prompt. This function can also be used to write a value to an external file when the optional file descriptor is provided.
    Syntax: (princ [expression [file_descriptor]])
  • prompt – Displays a text message or string value at the Command prompt.
    Syntax: (prompt message)

You might use the previously mentioned functions to display basic or more specific messages to help identify which code statements were recently executed. Examples of basic messages might be:

  • "Here1", "Here2", "HereX"
  • "Debug1", "Debug2", "Debug3"
  • "A", "B", "C"

More specific messages that you might use are:

  • "Starting While loop to modify selected objects"
  • "Updating DXF data for an object"
  • "Removing dictionary entries"

The previously mentioned functions are useful for displaying information in the AutoCAD user interface; it can also be beneficial to write messages and values out to an external log file.  In addition to the PRINC function, the following AutoLISP functions can also be used to output information to the Command prompt or an external log file:

  • prin1 – Displays a value assigned to a variable or returned by an expression, or a text message at the Command prompt or writes it out to an external file if a file descriptor is provided. Strings containing control characters are expanded.
    Syntax: (prin1 [expression [file_descriptor]])
  • print – Displays a value assigned to a variable or returned by an expression, or a text message at the Command prompt or writes it out to an external file if a file descriptor is provided.
    Syntax: (print [expression [file_descriptor]])

The following code example creates a blue circle using the ActiveX/COM library and demonstrates how some of the previously mentioned functions can be used to help debug a program:

; Load COM environment
(vl-load-com)

; Create a blue circle using Visual LISP
(defun c:CreateCircle-VL ( / acadObj docObj spaceObj cenPoint circObj)
  ; Create a reference to AutoCAD
  (setq acadObj (vlax-get-acad-object))

  (princ acadObj)
  (terpri)
 
  ; Create a reference to the current drawing
  (setq docObj (vla-get-activedocument acadObj))

  (princ acadObj)
  (terpri) 
  (prompt "Determine current space")
  (terpri)
 
  ; Get a reference to the current space
  (if (= (vla-get-activespace docObj) acModelSpace)
    (setq spaceObj (vla-get-modelspace docObj))
    (setq spaceObj (vla-get-paperspace docObj))
  )

  (princ spaceObj)
  (terpri) 
  (prompt "Start object definition")
  (terpri)
 
  ; Create the center point for the circle
  (setq cenPoint (vlax-make-safearray vlax-vbdouble '(0 . 2)))
  (vlax-safearray-fill cenPoint '(5.0 5.0 0.0))

  (princ cenPoint)
  (terpri)
 
  ; Create a circle at 5,5 in a radius of 1.75
  (setq circObj (vla-addcircle spaceObj cenPoint 1.75))

  (princ circObj)
  (terpri)
 
  ; Change the color of the circle to blue
  (vla-put-color circObj 5)

  (prompt "End object definition") 
  (terpri)
 (princ)
)

When executed, the previous example displays the values of several variables using the PRINC function and messages with the PROMPT function at the Command prompt. The following is a sample of the output displayed:

Command: CREATECIRCLE-VL
#<VLA-OBJECT IAcadApplication 00000001400d6188>
#<VLA-OBJECT IAcadApplication 00000001400d6188>
Determine current space
#<VLA-OBJECT IAcadModelSpace 000000003285d808>
Start object definition
#<safearray...>
#<VLA-OBJECT IAcadCircle 0000000039fe7f88>
End object definition

Once you are done debugging, you would normally comment out or remove each statement that simply outputs the values and messages that the user wouldn't normally need to see.  The downside to this though is that there could be hundreds of statements that you might need to comment out or remove each time you debug your program, what if there was a better approach to using messages to perform basic debugging.  Over the years, I created a utility library specific for handling debug messages. This library allows you to display messages at the Command prompt or to a log file, and even disable the feature all at once without needing to comment or remove the debugging statements.

The debug utility library that I wrote consists of three global variables and five functions:

  • *GLOBAL-DEBUG-LOGFILE* - Global variable that contains the log file name and location
  • *GLOBAL-DEBUG-LOGGING* - Global variable that can be used to determine if logging is enabled (T or nil)
  • *GLOBAL-DEBUG-ENABLED* - Global variable used to determine if debugging is enabled (T or nil)
  • debug-mode - Enables/disables the debug utility
  • debug-get-enabled - Gets the current status of the debug utility; enabled or disabled
  • debug-get-logmode - Gets the current status of log mode; enabled or disabled
  • debug-get-logfile - Gets the name and location of the log file
  • debug - Accepts the value that should be displayed at the Command prompt or output to the log file

The following is what the actual function definitions look like from my debug utility library:

; Global debugging variables
; *GLOBAL-DEBUG-LOGFILE* - Log file name and location
; *GLOBAL-DEBUG-LOGGING* - Log enabled
; *GLOBAL-DEBUG-ENABLED* - Enable debugging (T or nil)

; Enable debugging - Example usage (debug-mode 2)
; 0 or nil - Disables debugging
; 1 or T   - Enables debugging at the Command prompt
; 2        - Enables debugging and outputs to a log file

(defun debug-mode (enable / )
  (cond
    ((or (= enable 0)(= enable nil))
      (if (= (type *GLOBAL-DEBUG-LOGFILE*) 'FILE)
        (progn
          (close *GLOBAL-DEBUG-LOGFILE*)
          (setq *GLOBAL-DEBUG-LOGFILE* nil)
        )
      )

      (setq *GLOBAL-DEBUG-ENABLED* nil
            *GLOBAL-DEBUG-LOGGING* nil
            *GLOBAL-DEBUG-LOGFILE* nil)
    )
    ((or (= enable 1)(= enable T))
      (setq *GLOBAL-DEBUG-ENABLED* 1 *GLOBAL-DEBUG-LOGGING* 0)
      (if (= (type *GLOBAL-DEBUG-LOGFILE*) 'FILE)
        (progn
          (close *GLOBAL-DEBUG-LOGFILE*)
          (setq *GLOBAL-DEBUG-LOGFILE* nil)
        )
      )
    )
    ((= enable 2)
      (setq *GLOBAL-DEBUG-ENABLED* 1 *GLOBAL-DEBUG-LOGGING* 1)
      (if (/= (type *GLOBAL-DEBUG-LOGFILE*) 'FILE)
        (setq *GLOBAL-DEBUG-LOGFILE* (open (strcat (getvar "tempprefix") "global-debug.log") "a"))
      ) 
    )
  )
 (princ)
)

; Get the current state of debugging
(defun debug-get-enabled ( / )
  *GLOBAL-DEBUG-ENABLED*
)

; Get the current logging state
(defun debug-get-logmode ( / )
  *GLOBAL-DEBUG-LOGGING*
)

; Get the name of the current log file
(defun debug-get-logfile ( / )
  *GLOBAL-DEBUG-LOGFILE*
)

; Debug function is a wrapper for the functionality
; of the princ and print functions. Feature is turned on or
; off with the debug-mode function.
(defun debug (value / )
  (if (debug-get-enabled)
    (if (/= (debug-get-logmode) 1)
      (progn (princ value)(terpri))
      (print value (debug-get-logfile))
    )
  )
 (princ)
)

The following is a revision of the CreateCircle-VL, shown earlier in this posting, which demonstrates the usage of the debug utility library compared to separate PRINC and PROMPT functions:

; Load COM environment
(vl-load-com)

; Enable debug mode
(debug-mode 1)

; Create a blue circle using Visual LISP
(defun c:CreateCircle-VL ( / acadObj docObj spaceObj cenPoint circObj)
  ; Create a reference to AutoCAD
  (setq acadObj (vlax-get-acad-object))

  (debug acadObj)
 
  ; Create a reference to the current drawing
  (setq docObj (vla-get-activedocument acadObj))

  (debug acadObj)
  (debug "Determine current space")
 
  ; Get a reference to the current space
  (if (= (vla-get-activespace docObj) acModelSpace)
    (setq spaceObj (vla-get-modelspace docObj))
    (setq spaceObj (vla-get-paperspace docObj))
  )

  (debug spaceObj) 
  (debug "Start object definition")
 
  ; Create the center point for the circle
  (setq cenPoint (vlax-make-safearray vlax-vbdouble '(0 . 2)))
  (vlax-safearray-fill cenPoint '(5.0 5.0 0.0))

  (debug cenPoint)
 
  ; Create a circle at 5,5 in a radius of 1.75
  (setq circObj (vla-addcircle spaceObj cenPoint 1.75))

  (debug circObj)
 
  ; Change the color of the circle to blue
  (vla-put-color circObj 5)

  (debug "End object definition")
 (princ)
)

When the revised code is loaded and executed, variable values and messages are displayed at the Command prompt.  If you execute the statement (debug-mode 0) at the Command prompt or change the (debug-mode 1) statement to (debug-mode 0) and reload the sample code, debugging is disabled and the variables and messages are no longer displayed at the Command prompt.

Hope this article makes you think differently about utilizing basic messages when debugging your custom programs.

Sincerely,
  Lee 

Posted at 08:04 AM in AutoCAD, AutoCAD based products, AutoLISP/Visual LISP, Programming | | Comments (0)

| | | Pin It! | | |

Debugging AutoLISP Programs - Part 1

Debugging AutoLISP programs is "A Zen like Experience," said no one ever... Although, I have tried to convince a number of people that it is very a calming and soothing activity over the years.  There are a number of different debugging techniques and tools that can be used to find and handle errors much easier, whether you are developing in AutoCAD on Windows or Mac OS.

Note: There are more debugging tools available on Windows than Mac OS at this time, which could change in the future.  If you do plan on developing a number of AutoLISP programs, you might want to consider getting access to the Windows version of AutoCAD if you are a user of Mac OS.  Just a simple suggestion, not something you must do.

The thought of debugging and error handling doesn't come naturally to new and even seasoned developers, as most are simply focused on solving the problem at hand and not all the extra baggage that often goes with well written code.  Of course, well written code is in the eye of the developer that is look at it in the current moment.  Also if it isn't broken, then why change or fix a process\approach to a solution?  After many years of writing custom programs, I have learned that debugging and error handling need to be some of the very first things to consider when writing any custom program.

While I am just as guilty for jumping in (feet, hands, and compiler first) and writing code, this approach can get you to the solution faster but can lead to some bad habits and headaches down the road.  One of the things that I have found useful in getting me to slowdown and think things through more clearly is the creation of a flowchart.  If you are not already creating one today, I recommend creating a flowchart to help you visualize all the logical paths through your programs.  Flowcharts make it easier to identify choices as well as potential failure points that need to be handled.  A flowchart can also be a great way to communicate the design of a program with other that are less technical.  Products like Microsoft Visio or Lucidchart are designed to create flowcharts, but the same can be accomplished with Microsoft Word, PowerPoint, and other word processor and presentation products.

Potential failure points can be introduced when a:

  • User has an opportunity to provide input
  • Global variable is used
  • Program relies on a specific folder structure or an external data/support file, such as a drawing or text file or Windows registry entries
  • Program utilizes an ActiveX/COM or external library

AutoLISP/Visual LISP offers a variety of built-in functions and features to help you track down problems and handle errors. You can utilize the following debugging and error handling functions and features when developing your custom programs:

  • Basic debug messaging - AutoLISP functions alert, prompt, print1, prin1, and princ
  • Basic function tracing facilities - AutoLISP functions trace and untrace
  • Visual LISP IDE (Windows only) - Breakpoints, watch window, inspect window, and trace stack
  • Data validating functions - AutoLISP functions numberp, zerop, boundp, minusp, listp, vl-consp, type, vl-symbolp, and vl-file-directory-p
  • Error catching - AutoLISP functions vl-catch-all-apply, vl-catch-all-error-message, and vl-catch-all-error-p
  • Custom error handling - AutoLISP functions *error*, vl-exit-with-error, vl-exit-with-value, *pop-error-mode*, *push-error-using-command*, and *push-error-using-stack*
  • Undo grouping - AutoCAD UNDO command allows you to begin and end an undo group so that all changes made by your program can be reverted using the AutoCAD U command

Hope you find this overview topic helpful, I plan on following up with future articles that dive more into specifics about each debugging technique and tool that I mentioned.

Sincerely,
  Lee

Posted at 02:37 PM in AutoCAD, AutoCAD based products, AutoCAD for Mac, AutoLISP/Visual LISP, Programming | | Comments (0)

| | | Pin It! | | |

My Photo

My Other Accounts

Subscribe to this blog's feed

Search

Twitter Updates

    follow me on Twitter

    Recent Posts

    Recent Comments