March 14, 2019

ACA: Suppress Multiple Objects Contextual Ribbon Tab

Someone in my office today asked if the Multiple Objects contextual ribbon tab could be suppressed. That is the tab that displays when you select items of different object types.
The individual did not want to have to go back to the tab that was previously active where the tool to be used resided. I recalled that some years back, there were controls that would allow you to not have the ribbon focus shift to the contextual ribbon tab (it would activate, but not become the current tab), to have it show on a single-click or to have it show on a double-click. Those choices are no longer available.

What remains is the ability to set the maximum number of objects for which a contextual ribbon will display (RIBBONCONTEXTSELLIM System Variable). The allowable range is 0 to 32767, with an initial default value of 2500. The purpose of this is to limit performance issues when trying to act on a large number of objects. When the number of objects selected exceeds the current value of RIBBONCONTEXTSELLIM, then a contextual ribbon tab will not display, and any ribbon property controls will be disabled (grayed out). Setting the value to 0 allows an unlimited number of objects to be selected and still get a contextual ribbon tab, so this cannot be used to turn off contextual ribbon tabs. But setting it to 1 will allow contextual ribbon tabs to display when just one object is selected (which most would find desirable, particularly for AutoCAD® Architecture and AutoCAD® MEP objects), but disable it when more than one object is selected. This effectively suppresses the display of the Multiple Objects contextual ribbon tab, but does also suppress all other contextual ribbon tabs when multiple objects are selected. For example, if you select two or more Walls, the Wall contextual ribbon tab will not display.

In addition to typing RIBBONCONTEXTSELLIM at the command prompt, pressing the ENTER key and then typing 1 and pressing the ENTER key, you can also set this value in the Options dialog, on the Selection tab, in the Ribbon options area by selecting the Contextual Tab States button and then editing the value in the Object selection maximum for contextual tab display edit box.

This value is stored in the User Settings (registry) for a given AutoCAD Profile, so setting it once will apply to all drawings you open.

I personally leave the setting at the default 2500, but if you often select multiple objects of different types with the intent to select a tool on the ribbon that is not on the Multiple Objects ribbon tab and want to avoid having to perform an extra click to get back to where you previously were in the ribbon, then setting RIBBONCONTEXTSELLIM to 1 may improve your workflow.

February 28, 2019

ACA: Custom Display Block for Door in Plan View

You may have noticed that even after assigning a custom Profile to a Door to add a glazed panel to the Door, that there is no change to the graphics when viewing the Door in "plan" (Top view direction) in any of the out-of-the-box Display Representation Sets, That is because these use one of the "plan" Display Representations for Doors (Plan, Plan High Detail, Plan Low Detail, Plan Screened, Reflected or Reflected Screened), and the Panel component in these is 2D graphics representing the panel width and depth (overall Door width only, in Plan Low Detail) that is not tied to the 3D representation where the glazing is shown.

In my work, I have never needed to indicate glazing in a Door Panel at the typical scales used for plan views (1/16" = 1'-0" to 1/4" = 1'-0"). But if you do have a need for that, you can use a custom display block to add graphics to represent a glazed panel in plan views.

Before we dive into creating the block and assigning it to the Door Style, you need to understand the limitations of custom display blocks in plan Display Representations. The only component to which you can assign a custom display block in plan is the Frame component. You cannot assign one to the Panel component. That means you cannot scale the block by the thickness of the Panel, nor will the block rotate to match the swing angle of the Panel. If you use multiple swing angles for your Panels, you will need multiple display blocks and multiple Door Styles (one of each for each angle). For a 90-degree Panel swing angle (the one we typically use for new construction Doors), scaling the custom display block by the Width, even with the Frame Component set to Inside, will not scale the block along the width of the Panel, but perpendicular to the width of the panel (because ACA thinks it is a Frame component). All of this means that if the graphics in the file need to be accurately shown, and not just a "symbol", you will need a separate custom block and a separate Door Style for each Door width.

If all of that did not change your mind about showing a glazed panel in plan views for Doors, here is how to do it.
  1. Identify the Door Style that is to receive the custom display block. For this example, I have a style called Wood Door with Glazing that has a custom Profile assigned as the Shape on the Design Rules tab of the Door Style. That creates a glazed panel in a model view, but has no effect on the plan view graphics, as seen in the image below.
  2. Verify that the target Display Representation for Doors is active in the current Display Configuration. In this example, the custom display block will be attached to the Plan Display Representation for Doors, and that is active in my current Display Configuation.
  3. Place an instance of the Door in the drawing, and set the Width property of the Door to the width intended for the display block. Having an instance in the drawing is helpful for seeing the effects of the editing so far, and, in cases like this where no scaling will be applied to the block, can be used when generating the linework for the block definition.
  4. Determine where the insertion point of the custom display block will be. In this case, the hinge-side corner of the frame (where it meets the corner of the Door Panel) is an appropriate insertion point.
  5. Draw the linework for the custom display block. If you want to be able to control the display of the linework in the display properties of the Door Style, draw the linework on Layer 0, and assign ByBlock to the Color, Linetype, Plot Style (if using named plot styles), Lineweight and Transparency properties of the linework. In this example, the linework consists of two lines perpendicular to the width of the Door Panel, set in 10" from each end of the Door Panel, and a third line connecting the midpoints of the first two lines, to give a symbolic representation of the glass panel in the Door.
  6. Create the block definition from the linework, being careful to specify the desired insertion point. If you choose to retain the linework or convert the linework to a block, move the linework or block to the side, so that it will not obscure the results of adding the custom block to the Door Style.
  7. Select the Door and, on the Door contextual ribbon tab, on the General panel, select the Edit Style tool. (Or, if you prefer, open the Style Manager, navigate to and select the Door Style in the left pane so that you can edit the style in the right pane.)
  8. Choose the Display Properties tab. The currently active Display Representations will be displayed in bold type. In this example, both the Plan and Threshold Plan Display Representations are active. As the Threshold Plan Display Representation does not allow for attaching custom display blocks, the Plan Display Representation will be used.
  9. Select the Display Representation to receive the custom display block. Left click the toggle in the Style Override column for that Display Representation, to add a display override and open the override for editing.
  10. In the Display Properties dialog, select the Other tab. In the Custom Block Display area, select the Add button.
  11. In the Custom Block dialog, select the Select Block button. Choose the block you created in the Select a Block dialog and select the OK button to return to the Custom Block dialog. The block should show in the viewer.
  12. Back in the Custom Block dialog, change the Insertion Point Y: value to Back and set the Frame Component to Inside. When I did this, the block shifted when I changed the Y setting of the Insertion Point, but did not move when I changed the Frame Component to Inside.
  13. I chose to let the Display setting at Always. If you want to limit the situations where the block will display, select one of the other options: When Intersecting Cut Plane, When Above Cut Plane or When Below Cut Plane, and the block will only display when the selected option is true.
  14. Select OK to ratify the changes, close the Custom Block dialog and return to the Door Style Properties dialog.
  15. If you are a bit leery about the fact that the viewer was showing the custom block outside of the Door Panel, you can select the block name that now shows in the list box in the Custom Block Display area and choose the Edit button. That will reopen the Custom Block dialog and the viewer will properly update and show the block inside the Door Panel, where it belongs. If you are not making any changes, you can select the Cancel button to dismiss the Custom Block dialog; otherwise select the OK button after you are finished with any changes.
  16. In the Display Properties dialog, select the Layer/Color/Linetype tab. Notice that the custom display block now appears as a Display Component. You can make any edits here that you desire. I chose to let the default settings (Layer 0, with ByBlock properties), so that the block will inherit its properties from the parent Door object, just like the Panel, Frame and Swing components. You may want something different. Keep in mind these settings will only be apparent if the linework within the custom display block is on Layer 0 with ByBlock properties, as previously noted.
  17. When you are done editing the properties of the custom display block component, select the OK button to return to the Door Style Properties dialog. Notice that there is now a check mark in the Style Override column and that the Display Property Source now shows Door Style Override - [YOUR DOOR STYLE NAME HERE] rather than Drawing Default. Select the OK button to accept all of the changes to the Door Style and return to the drawing.
    NOTE: If you ever need to edit the display settings for this Door Style's Plan Display Representation, select it and choose the Edit Display Properties button in the upper left of the dialog. Do NOT select the Style Override toggle again; that will clear the toggle and remove the override. If you do that unintentionally, select the Cancel button to exit the dilaog without making any changes, or you will have to recreate the override.
The instance of the Door Style in the drawing should now reflect the addition of the custom display block (assuming that you edited an active Display Representation, as directed above). In the image below, the custom display block instance is at the left and selected, and the Door instance, now showning the custom display block, is at the right.

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

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)"

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 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.

December 19, 2018

Revit 2018: Disabling Addins to Resolve Cloud Render Issue

If you ever have an issue with Revit being unable to upload a model for a cloud rendering, you will likely end up on this Autodesk Knowledge Network article, and may eventually get to the suggestion to disable the addins to see if there is a conflict with one of them, which links through to a second Autodesk Knowledge Network article.

The second article helpfully lists a number of addins that should be left in place if you are using the Collaboration for Revit service. What it does not list is the addin that generates the Render in Cloud tool on the View ribbon tab, on the Presentation panel. It is rather hard to test whether removing the addins allows a cloud render to go through if the tool to initiate a cloud render is gone.

I was able to work out that the RaaSForRevit folder should not be removed from the W:\ProgramFiles\Autodesk\Revit 2018\AddIns folder if you want to have the Render in Cloud tool.

December 18, 2018

No More 32-bit AutoCAD

See this Autodesk Knowledge Network Article for details on the discontinuation of a 32-bit version of AutoCAD, starting with the next release.

December 09, 2018

Dynamo: Export Views and Sheets from Revit - Part 6

First post in this series [Part 1]
Previous post in this series [Part 5]

We now have all of the user input needed to create the export, and we have taken the user-specified ViewSheetSet and generated a list of the View and Sheet objects included in the ViewSheetSet and a corresponding list of names to be used for the exported Views and Sheets. All that remains is to do the actual export. The Python Script 2 node in the Export to DWG group does the export.
There are six inputs to this node:
  • IN[0]: This input takes the folder the user specified as the destination for the exported drawing files (see Part 1).
  • IN[1]: The recombined list of Views and Sheets is sent to this input (see Parts 2 and 3).
  • IN[2]: This input receives the list of generated file names for the exported Views and Sheets (see Part 4).
  • IN[3]: The name of the DWG Export Setup to be used is sent to this input (see Part 5).
  • IN[4]: The user choice of whether to merge the Views on a Sheet into one drawing file (true) or not (false) is received by this input (see Part 5).
  • IN[5]: The user choice of whether to actually export the Views/Sheets (true) or to just run the graph without exporting (false) is sent to this input (see Part 5).

The image below shows the Python code that processes this input. The majority of this code was written by Konrad K Sobon, and posted to this thread in the DynamoBIM forum. It also includes the ability to have exported Sheets to have the Views on the Sheet merged into the View drawing file, rather than exported as separate drawing files that are then externally referenced by the Sheet drawing file. This addition was posted to the DynamoBIM forum by 4bimfercesp in this thread. The ability to specify the name of an existing DWG Export Setup comes from code posted by Andrea_Ghensi in the same thread in which Mr. Sobon posted his code. As I read through the postings and assembled the code shown below, I added some additional comments to solidify my understanding of what the code is doing.

If there are no errors generated in the course of performing the requested export, the Python Script 2 node outputs a string, Success!. This is displayed in the Watch node to the right of the Python Script 2 node. If there is at least one error, then the error report is the output, and is displayed in Watch node to aid in sorting out what went wrong. If the user input in the Group 5 area is false, indicating that the export is not to be done, then the output is a reminder to set the Ready to Export Views and/or Sheets - Boolean node to true to perform an export.

If you need to export the same Views and/or Sheets multiple times as a project makes its way through the design and documentation process, this graph can be a time saver while improving consistency. Customize a copy of it for each project, and use Dynamo Player to be a few clicks away from a new set of export files at any given moment.

December 06, 2018

ACA: Multi-View Blocks and DRAWORDER

A reminder for those who already know about this, and a heads up for those who do not. Multi-View Blocks do not respect any dipslay order modifications made to the nested objects in the AutoCAD block assigned as a view block to the Multi-View Block. So if you use the DRAWORDER command to get things to look the way you want in the AutoCAD block, those changes will not show up when that block is assigned to a Multi-View Block Definition and an instance of that definition is placed in your drawing file.

For example, suppose you have a custom Space Tag that includes a an overall rectangle with a dividing line that separates the Space name from the Space number, as illustrated in the image below.
Further suppose that you often place these tags in areas where there is linework "below" the tag, and you would rather not have that show inside the outer rectangle, so that the name and number can be more easily read. You might decide to add a Wipeout to the view block to accomplish this task. So you place an instance of the view block, edit it in place (or in the Block Editor) and use the WIPEOUT command to add a Wipeout to the Block Definition, using the outer rectangle, which just happens to be a closed Polyline, to do so (without erasing the Polyline). So far, so good. Before saving the changes to the Block Definition, you select the Wipeout, right click and choose Basic Modify Tools > Display Order > Send to Back from the context menu, to execute the DRAWORDER command and send the Wipeout to the back of the draw order. After saving the changes back to the Block Definition (and closing the Block Editor, if you used it), you see that the instance of the view block is working as desired - the Wipeout is hiding linework under the view block instance, while showing all of the other linework in the block definition.

But when you examine your Space Tags, you find that while the tags now hide linework "below" them, the line between the room name and room number is no longer visible. If you select a Space Tag, that line is highlighted, so you know it was not accidentally erased or otherwise removed from the Block Definition, but it does not show. (Attributes seem to be treated differently from other linework, and do still appear on top.) What gives? Multi-View Block instances do not respect changes in draw order, and display the items within the view block definition in the order in which they were added to the Block Definition.

What to do? Do not use the DRAWORDER command to put things in the desired order - draw them in that order. You do not have to recreate the Block Definition for the view block from scratch. You can proceed as mentioned earlier, but after creating the Wipeout, instead of using DRAWORDER to push the Wipeout to the back, select all of the objects other than the Wipeout and use the COPY command, with a Displacement of 0,0, to create a new copy of each item in the same place. Then use the ERASE command, with the Previous command line option, to erase the objects you just copied. Now the Wipeout is the first item drawn in the Block Definition, and you can save the changes and have the desired draw order respected in both the view block and the Multi-View Block.

In the image below, the same Spaces and Tags from the first image are shown. The Space Tags, while appearing identical, are actually instances of two different Multi-View Block Definitions, each with its own view block. The view blocks just happened to have equivalent contents. The Space Tag in Space 101 had a Wipeout added to the view block, pushed to the back using the DRAWORDER command. The Space Tag in Space 102 had a Wipeout added to the view block, and then the other items in the Block Definition were copied in place, and the originals erased. The line between the room name and number is hidden by the Wipeout in 101, but is seen in 102.

November 29, 2018

Dynamo: Export Views and Sheets from Revit - Part 5

First post in this Series [Part 1]
Previous post in this series [Part 4]

So far in this series, we have seen nodes that allow the user to specify a folder to receive exported drawing files, a node for the user to enter the name of a ViewSheetSet which lists the Views/Sheets to be exported, the nodes that generate a list of Views/Sheets that are in that Set, nodes to separate that list into separate lists of just Views and just Sheets, and the nodes that generate file names to be used for the exported Views and Sheets. This post will examine the balance of the user input nodes.

Each of these three input nodes includes a second "Passthrough Value" node, which are renamed Code Blocks and, as the node title suggests, simply pass through the value from the input node. They are not at all necessary, and are only there to make the group each is in wider, so that the rather long group titles will only take up two lines of text.

The Name of DWG Export Setup - String node (Group 3) is a String node into which the user enters the name of the DWG Export Setup to be used for the exports. This can be left blank if the user wants to use Revit Default settings.

The Merge Views on Sheet into one DWG File? - Boolean node (Group 4) is a Boolean node that allows the user to choose whether Views on a Sheet should be exported as one DWG file (True) or if the Views should be exported as separate DWG files that are externally referenced into the exported Sheet (False).

The Ready to Export Views and/or Sheets - Boolean node (Group 5) is a Boolean node. Setting this to False allows the user to enter data in the other nodes and Run the graph to view the results in the Watch nodes, verifying that all is correct before actually exporting any files. When all is ready to go, set this to True and run the graph one more time to export the Views/Sheets.

All three of these input nodes, like the other two, are set to be input nodes (see first post), so that they are available if this graph is run via Dynamo Player. The next and final post will examine the Python Script 2 node and the code inside it, that does the actual exporting.