January 22, 2019

ACA: Unable to execute the tool. Unspecified error.


Had a support request today for the error dialog shown above, from someone working on a file in AutoCAD® Architecture 2016, who was trying to use a Wall Tool when the error occurred. That was all I was initially told, and "Unspecified error" is not terribly helpful. I asked the user to verify what AutoCAD profile was current and whether the problem was just with one file, or all files. In the course of responding, the user provided additional information. The problem was with just this one file, which had been working properly earlier. The reason the Wall Tool was being used was to fix Walls that were now "faulty." And when opening the file, this other dialog appears:


Bingo! The file had been opened and saved in AutoCAD Architecture 2018. Most likely, SAVEAS was used to set the file format to the 2013 file format, but that left the AEC objects in the file, including the Walls, in the 2018 file format. Those future objects disabled the AEC Commands, leaving the Wall Tool with no command to run. Add that to the list of reasons for getting an Unable to Execute The Tool error dialog.

January 14, 2019

ACA: Accessing AEC Data in Formula Properties for Multiple Versions

2019-09-09: Updated to include AutoCAD Architecture 2020.

Some "advanced" formula properties (see this blog post for an example) that pull in AEC Data not available in the automatic properties have to reference one of the AEC modules, and need to include the first two version numbers for the current version of AutoCAD® Architecture or AutoCAD® MEP that is running. The version numbers can be obtained by running the AECVERSION command in a given version. For example, AecX.AecBaseApplication.8.1 is the Aec Base Application module for the 2019 version.

If you want a formula property to work across multiple versions, it has to know what version is running to be able to call the correct application version. For a small number of versions, that can be built into the formula property without too much difficulty or confusion (see previously linked example). But I recently had a reason to revisit a formula that retrieved the elevation of a ceiling object (based on the Wall elevation formula in the example blog post), and, over ten years later, there are more than a small number of versions that could be supported. In this case, I decided that it made more sense to pull out the code to determine the AECVERSION numbers into a separate formula property. This would be particularly effective if multiple formula properties needed to access it. Taking it one step farther, the following code will give you just the numeric suffix, which the primary formula property could then concatenate with the name of the Aec Application being referenced. Versions 2008 through 2019 are supported by this code.
Set acadApp = GetObject(,"AutoCAD.Application")

'ACADVER values:
'ACD-A2008 = "17.1s (LMS Tech)"
'ACD-A2009 = "17.2s (LMS Tech)"
'ACD-A2010 = "18.0s (LMS Tech)"
'ACD-A2011 = "18.1s (LMS Tech)"
'ACD-A2012 = "18.2s (LMS Tech)"
'ACD-A2013 = "19.0s (LMS Tech)"
'ACD-A2014 = "19.1s (LMS Tech)"
'ACD-A2015 = "20.0s (LMS Tech)"
'ACD-A2016 = "20.1s (LMS Tech)"
'ACD-A2017 = "21.0s (LMS Tech)"
'ACD-A2018 = "22.0s (LMS Tech)"
'ACD-A2019 = "23.0s (LMS Tech)"
'ACD-A2020 = "23.1s (LMS Tech)"

acadVerString = acadApp.ActiveDocument.GetVariable("ACADVER")

'Set ACD-A application string, based on version running:
Select Case acadVerString
 Case "17.1s (LMS Tech)"
  RESULT = ".5.5"
 Case "17.2s (LMS Tech)"
  RESULT = ".5.7"
 Case "18.0s (LMS Tech)"
  RESULT = ".6.0"
 Case "18.1s (LMS Tech)"
  RESULT = ".6.5"
 Case "18.2s (LMS Tech)"
  RESULT = ".6.7"
 Case "19.0s (LMS Tech)"
  RESULT = ".7.0"
 Case "19.1s (LMS Tech)"
  RESULT = ".7.5"
 Case "20.0s (LMS Tech)"
  RESULT = ".7.7"
 Case "20.1s (LMS Tech)"
  RESULT = ".7.8"
 Case "21.0s (LMS Tech)"
  RESULT = ".7.9"
 Case "22.0s (LMS Tech)"
  RESULT = ".8.0"
 Case "23.0s (LMS Tech)"
  RESULT = ".8.1"
 Case "23.1s (LMS Tech)"
  RESULT = ".8.2"
 Case Else
  RESULT = "Unknown"
End Select

Note that any line beginning with a single quote is a comment, and is ignored when the VBScript code is evaluated. The ACADVER values shown in the initial comments could be removed; I like to keep them for easy reference, as I tend to forget the ACADVER value for any given release.

January 12, 2019

Dynamo: Getting a List of All Label Types

We have a client with specific font standards in AutoCAD® that I suspect will carry over into Revit®. These differ from our office standards, so I was looking for a way to more easily change the fonts used for various text entities in a project file started with our template file or loadable families, and hoping to use Dynamo as part of the solution.

In a project file, getting all of the TextNoteTypes (for Text) is fairly straightforward. Start with an Element Types node set to "TextNoteType" and feed it to an All Elements of Type node. In a family file where Labels are present, getting a list of TextElementTypes is a little more complicated, if you do not want them mixed in with TextNoteTypes, as setting the Element Types node to "TextElementType" and feeding the output to an All Elements of Type node will return both types. A List.FilterByBoolMask node can be used to separate the two types, if your application needs to operate on just one or the other type (or both, but separately). The image below illustrates one possible arrangement, where the in ouput will have a list of the TextElementTypes (Labels) will and the out output will have a list of the TextNoteTypes (Text).
The List.FilterByBoolMask node in the green area is the node with the separated lists. The other List.FilterByBoolMask node in the upper right is there just to show the Family Name parameter value of each Type, to verify that the mask worked as desired, and can be deleted.