October 20, 2016

Revit Families: Yes/No Parameter Defaulting to No

When you add a Yes/No parameter in a Revit® family, the initial default value is "Yes" - the box in the Value column is checked. If you only have one Type in your family at the time, it is easy enough to uncheck the box if you want it to be set to "No" and to have the value be "No" for any other Types created while that Type is current.

But there are occasions, such as for visibility parameters, where a family may get created, with multiple Types, and then later edited to add a new Type that requires a new Yes/No parameter that should only be turned on for the new Type. It is tedious to set each existing Type current and uncheck the newly added Yes/No parameter if there are more than two or three existing Types. Unfortunately, there is no way to specify the initial value for a newly added Yes/No parameter. Thanks to this post in the Who's afraid of the Big Bad BIM? blog, I have worked out a way to quickly get all types set to "No". I believe that what follows is the full intent of what the original article posted, but the article stops short of clearing the formula so that one or more of the Types can be set to "Yes" and therefore also does not note the need to change to a different Type when clearing the formula, so that all Types remain unchecked. [Perhaps that was not necessary in whatever version Erik was using in the summer of 2012 when the article was written.]

  1. Add a new Yes/No parameter to a Revit family with multiple Types, in which you want most of the Types to be set to "No".
    Note that all of the Types will be initially set to "Yes" (checked).
  2. In the Formula column for the newly added Yes/No parameter, type 1=0, and then press the ENTER key. Any expression that evaluates to false will do.
    Note that the toggle in the Value column is now unchecked, but it is also grayed out and locked, because it is being controlled by the formula.
  3. Set a different Type to be the current Type.**
  4. Delete the formula for the newly added Yes/No parameter.
  5. All of the Types are now set to "No". If you want any to be set to "Yes", set each one current, in turn, and select the toggle to check it.
The Screencast below shows the above steps in action. It also shows a second Yes/No parameter being added where the formula is deleted immediately after it was added, with the result that only that one Type is set to "No".
** - In Revit 2016, I found that if I deleted the formula in the Type in which I originally placed it, immediately after placing it, that only that Type remained set to "No", and the others remained checked. If you want, you can change to another Type and then change back to the original to do the deletion. There may be other actions which will "set" the "No" values for all Types.

September 02, 2016


I have been working on files that were created by others recently, and they contain a large number of Block References created using the PASTEBLOCK command, and left with the random name that gets assigned to the Block Definition by the PASTEBLOCK command. The names all start with A$C, followed by eight characters that appear to be a hexadecimal number. I find this very annoying, as you have no idea what is in any of these blocks, whereas you might if a meaningful name had been given.

Part of my current task required me to find things inside these annoying Block References, so I have been WBLOCKing them out to separate files and then opening those files to view the contents in isolation from all of the other things in the original file. I made an interesting discovery: when opening these files, the file name does not appear in the title area of the AutoCAD window and, in AutoCAD Architecture 2014 and 2016 (and, I suspect, all other versions that have File tabs), a file tab is not generated for these files. They are listed by the Switch Windows tool on the View ribbon tab, on the Windows panel, and they also appear in the Application Menu's Recent Documents list. So why do they not have drawing tabs or have their names in the title bar?

I thought there might be something wrong with my installation, so I did some admittedly brief searching on the Internet and in the online Help, and did not find any mention of this "situation." Surely I cannot be the first person to try this; perhaps I am the only one who thought it was odd.

It does not appear to be anything inside the WBLOCKed file itself. If I save the file under a different name, that does not follow the format of A$C followed by a hexadecimal number, and open that file, the file name will appear in the title area and a drawing tab will be generated. If I manually create a file and save it with a name that does follow that format (the length of the hexadecimal number does not appear to matter; so long as all of the characters that follow the initial A$C are taken from the numerals 0-9 and the letters A-F), when opened, the file name will not appear in the title area and a drawing tab will not be created.

This is not that big of a deal; I am writing this so that when I come across this in five years, having forgotten about it in the mean time, there will be at least one Internet source that discusses it.

August 24, 2016

Dropbox and Open/Save Issues in AutoCAD and Revit

Like many others, I experienced the problem with the 8.4.19 (8/16/2016) build of Dropbox. In my case, Revit® 2014 would display the whirlpool of death when selecting Open > Project from the Application Menu or selecting the Open link under Projects in the Recent Files window. I did not have any problems with AutoCAD®.

I just forced the current build of Dropbox to install (8.4.21), and I no longer have that issue.

For the record, here are the Autodesk Knowledge Network articles related to this issue:
AutoCAD becomes unresponsive when opening or saving files
Revit: Hang when clicking Open after recent Dropbox update

August 14, 2016

Dynamo - Element Parameters

If you are relatively new to Dynamo and not intimately familiar with the Revit API, like me, you may find this relatively simple graph of use.
The Select Model Element node at the upper left allows you to select an element in your Revit model and will report back, through the two Watch nodes at the right, the available instance parameters and their current values. These are the parameters that work with the Element.GetParameterValueByName and Element.SetParameterValueByName nodes. This can be helpful in identifying the parameter you need to access for a particular task.

The Element.Parameters node generates a list of these parameters, the Element.Name node takes that list and turns it into a list of the parameter names, as strings, and the List.Sort node sorts that list alphbetically. The left Watch node displays this sorted list; the list is also fed into the Element.GetParameterValueByName node, which generates a list the values for those parameters, for the selected element, and displays them in the right Watch node. My experience has been that the Element.Parameters node will list the parameters found in what seems like a random order that makes it hard (for me, anyway) to track them from element to element. The description of the Object.Identity node states that it passes out what is passed into it, doing nothing, which, I suppose, it true, but I included it here because by locking the Data Preview of the node in the open position, it shows the element category as well as the element ID number, whereas the Select Model Element node only shows the element ID number. Seeing the element category helps me be sure that I selected the desired element correctly.

Here are two screen shots of this graph in action, one with a Wall selected, and the other with a Dimension selected.
As always, you can select any of the images to see it full size.

July 29, 2016

ACA/AMEP: "BIND" Bound External Reference Named Object Naming

Whenever possible, I try to avoid binding External References with the BIND option; I prefer to use the INSERT option when I cannot leave the references as external. In cases where the "root" layer (for example, A-Door) has the same layer attributes and is treated the exact same way, whether as a "live" layer in the host file or a layer within one or more external references, using the INSERT option simply combines all of the various layers with the same root name into one layer (A-Door in the example here). But there are times when one has to work on a project done by others (perhaps, many others, over a long period of time), where the various layers with the same root name (A-Door, External01|A-Door, External02|A-Door, etc.) are not treated the same way, in particular, with regard to on/off, freeze/thaw and/or viewport freeze/thaw status. If A-Door is on, thawed and viewport thawed, External01|A-Door is globally frozen and External02|A-Door is viewport frozen, using the INSERT option of the BIND command will not preserve what is seen in the sheet. (Or, maybe it does, if nothing on that layer is visible in the viewports on that sheet - but if you are tasked with preparing hundreds of files for turnover at the end of a project on which you did not work, including disciplines other than your own, you will likely not have time to carefully note what is visible in each viewport on each sheet and then reproduce that.) Using the BIND option of the BIND command may be the best course in this case.

I have been involved in such an effort lately, and in the course of that have come to a clearer understanding of how named objects are renamed when using the BIND option of the BIND command. I knew that the named objects in each external reference were renamed, using the external reference name as a prefix, with the vertical bar (|) delimiter being replaced with, typically, $0$. So, External01|A-Door would become External01$0$A-Door. A long time ago, when all this was new to me, I (erroneously) thought that the "0" in the delimiter was the layer name on which the external reference resided, as back then most, if not all, of our external references were placed on Layer 0. At some point, I did a "bind-bind" on an external reference on a different layer, and still got $0$ as the delimiter, and realized that the "0" was not the layer name on which the external reference was at the time of binding, but did not give it a whole lot of additional thought.

In my current effort, I am writing AutoLISP code to help automate certain processing tasks which involve being able to specify layer attributes for the root layer name, and have those applied to all variations of that root layer name, whether or not the layer has a prefix/delimiter from having been "bind-bound". I wanted my code to be able to identify the final delimiter in a layer name, so that the root name could be extracted. I made a very brief attempt to find something in the Help that described how the delimiter is determined, without any success. (It may be in there, and I just did not have enough patience to find it.) So I played around with some test files, with a very small number of layers, to figure out if the delimiter could ever be anything but $0$. As it turns out, it can, but, at least for the way we work, it will almost always be $0$. Your experience may vary, as your workflow may differ from ours.

When you bind-bind an external reference, AutoCAD® will create unique names for all of the named objects in the external reference, whether or not there is a named object of the same type and name in the host file. It does this as previously noted, by starting with a prefix that is the same as the external reference name (which may or may not be the same as the external file name), adding a delimiter consisting of a $ character followed by an integer followed by a $ character, and finally the root name of the named object. The first time you bind-bind an external reference of a given name, that integer will be 0. Should you later add an external reference of that same name (having renamed the bound block -OR- exploded the bound block and purged the definition), and then bind-bind that reference, AutoCAD will see that there already are named objects using the $0$ delimiter, and will increment the integer to "1" - $1$. Do all of that again, and the delimiter will be $2$. Do it eleven times, and the delimiter becomes $10$.

Armed with that knowledge, I was able to write code that would examine the layer names character-by-character, starting at the right end, and would collect the root name in a variable. Once a $ character was found, if it is preceded by one or more integers and then another $ character, that delimiter was saved and the routine then had both the root layer name and the last delimiter in the layer name, allowing the routine to be able to process things accordingly. (If you externally reference a file that has itself had an external reference bind-bound, and then bind-bind the reference, you can get named objects with multiple delimiters, such as External01$0$PreviouslyBound01$0$A-Door.)

June 28, 2016

ACA: AEC Modify Tools, Part 7, AEC Crop

First post in series [AecLineworkExtend]
Previous post in series [AecLineworkMerge]

The AecLineworkCrop command can be found on the Home ribbon tab, on the Modify panel flyout, by selecting the Crop tool from the Obscure/Crop flyout. If the Crop tool is not displayed on the Obscure/Crop flyout, select the right side of the split button (down arrow icon) to deploy the flyout and choose the Crop tool. Or, with no command active, you can right click in the drawing window, and choose AEC Modify Tools > Crop from the context menu.

The AecLineworkCrop command is used to modify the extents of closed Polylines, Circles, Hatches, AEC Polygons, Mass Element Extrusions that have an embedded profile and Spaces, as well as Block References which contain any of these objects by "cropping" the original object to a boundary defined by one or more other objects. In lieu of selecting one or more objects to serve as the crop boundary, you can also specify a rectangular area by selecting its opposite corners. You will be given the option to erase any object(s) selected to define the crop boundary; the default is No, which leaves the crop boundary object(s) in the drawing file.

If you select multiple objects at the first prompt, the AecLineworkCrop command is applied to each of those independently, using the objects selected at the second prompt on each of those selected at the first prompt.
Here are some additional notes regarding the AecLineworkCrop command:
  • Open linework (Lines, Arcs, open Polylines) can be selected as objects to be cropped. If they extend beyond the crop boundary, they will be trimmed to it, but will remain open items of the same object types as the pre-cropped objects.
  • Closed objects, including Circles and closed Polylines, can be selected as objects to be cropped. If a Circle is modified by the AecLineworkCrop command, the result will be one or more closed polylines.
  • MText, Text, Ellipses and Ellipse Arcs cannot be selected as objects to be trimmed, but they can all be used to define the crop boundary. For MText and Text, the bounding box of the text is used as a rectangular crop boundary.
  • Mass Elements with a shape other than "Extrusion" and Mass Element Extrusions that have an external Profile can be selected as linework to be cropped, but will not affected by the AecLineworkCrop command. These types of Mass Elements can be selected as an object to define the crop boundary.
  • If a Block Reference is selected as an object to be cropped, only those nested objects within the block on which the AecLineworkCrop command works will be affected.
  • Attributes within a Block Reference will not be affected by the AecLineworkCrop command.
  • If a Block Reference is selected as linework to be cropped, it has nested elements that can be affected by the AecLineworkCrop command and it is the only instance of that Block Reference in the drawing, then the original block definition will be redefined to include the effects of the crop. If at least one instance of the Block Reference remains unaffected by the crop, then the original block definition will remain unchanged and the affected instance(s) will become instance(s) of new, anonymous block definition(s).
  • If a Block Reference is selected as linework to be cropped and it has multiple nested elements which can be affected by the AecLineworkCrop command, the crop will be applied to each of those elements independently.
  • Multi-View Blocks can be selected as linework to be cropped, but will not be affected by the command.
  • If the active View Block of a Multi-View Block contains linework or objects that can define a crop boundary or part of a crop boundary, it can selected as such.
  • Selecting an associative Hatch as linework to be cropped will result in a non-associative Hatch, regardless of whether or not the boundary of the Hatch is also selected as linework to be cropped the same AecLineworkCrop command.
  • Associative Spaces, Walls, Doors, Windows and Door/Window Assemblies can be selected as linework to be cropped, but will not be affected by the command. These objects can be used to define a crop boundary. Non-associative Spaces can be modified by the AecLineworkCrop command when selected as linework to be cropped.
  • Selecting a single line as the crop boundary will result in no change to the linework to be cropped. You will see this message at the command line: Failed to create a crop boundary from the selected objects. Selecting two lines, even if parallel, will allow a crop boundary to be calculated and applied, but the results may be unexpected.
  • The object(s) defining the crop boundary do not have to form a closed loop. If multiple objects are selected, they do not have to meet endpoint to endpoint, although the results may be unexpected if there is overlap or a gap.
  • Use a closed boundary (or a series of objects forming a closed boundary) for more predictable results.

There are object types and combinations of objects within a Block Reference that I did not test. When using the AecLineworkCrop command in a situation that you have not previously encountered, you may want to use the Mark option of the UNDO command, so that you can easily UNDO Back to the point before the command was used if you get unexpected results.

May 30, 2016

Dynamo - Filter by Type Parameter

I created another custom node for my fire/smoke rating Detail Item placement graph, previously discussed here and here. The previous two nodes gave me a list of all of the straight Walls visible in the current plan View, whose Base Constraint matched the level of the current View. In order to apply the correct Detail Item to each fire/smoke rated Wall, that list needs to be filtered, based on the fire-resistance-rating and whether the Wall is a smoke partition or smoke barrier. This information is stored in a type-based parameter for the Wall Types. I needed to repeat this multiple times in this graph, and since it also seemed to me that this was something that will have use in future projects, I created a custom node.

The custom node takes three inputs, one for the list of Elements (Walls) to be filtered, one for the name of the Parameter that is the basis for the filter and one for the value of the Parameter that will determine which Elements are "in" and which are "out".

The filtering is done in a similar way that the straight Walls were filtered, except this time, instead of using the fact that an empty string would be returned as the value for an instance-based parameter that was not present on the straight Walls, the Element Type of each Wall needs to be retrieved, using an Element.Type node, and then the value of the filtering parameter obtained from that by an Element.GetParameterValueByName node. An == (x equal to y) node is again used to generate a Boolean Mask list of trues and falses.

The Boolean Mask list is then used in a List.FilterByBoolMask to put the Elements that match the parameter in the "in" output and those that do not in the "out" output.

The entire graph of the custom node is shown below.

May 26, 2016

Dynamo - Filter Straight Walls

As part of the Dynamo project for which I developed the Active View Walls at Plan View Level custom node, I also needed to be able to operate on straight Walls and radiused Walls separately. I ended up making a custom node to handle this, to both make the main graph easier to read and so that I could easily reuse the "code" should I need to do this in a different graph in the future.

The graph of the custom node is fairly straightforward, as you can see in the image below. (Click on any reduced-size image to see the image full size.)
A brief description of the various parts and what they do follows.

While my current application passes this node a list of Walls, I decided that may not always be the case in future graphs, so the first set of nodes uses a RemoveIfNot node to strip out any element in the list that is not a Wall.

While poking around in the properties that were available on the Walls in my test project, I noticed that radiused Walls have a parameter called Center Mark Visible, while straight Walls do not. When getting the parameter value for Center Mark Visible, straight Walls will have an empty string value, while radiused Walls will have a value of 0 (center mark not visible) or 1 (center mark visible). I chose to use this as the way to determine if a Wall was straight or radiused. The next set of nodes generates a list of Booleans (true or false) that parallels the list of Walls. The corresponding Boolean will be true if the Center Mark Visible parameter value for the Wall is an empty string (straight Wall) or false if the value is not an empty string (radiused Wall).

The list of Booleans generated by the previous set of nodes is used as a "Boolean mask" by a List.FilterByBoolMask node and applied to the list of Walls to generate two separate lists. The "in" list contains all of the Walls with a corresponding Boolean of true, or all of the straight Walls. The "out" list contains all of the Walls with a corresponding Boolean of false, or all of the radiused Walls.

The in and out lists are connected to the Straight and Curved outputs of the custom node, so that the main graph has access to the two filtered lists. This custom node was developed in Dynamo 0.8.2, but has been successfully used in the 0.9.1 and 1.0.0 versions as well.

April 30, 2016

ACA/AMEP 2017: Styles Browser Enhancements

Several enhancements have been made to the Styles Browser, first introduced in the 2016 release of AutoCAD® Architecture and AutoCAD® MEP.

Add Directory to Content Library
For reference, the image below shows the Content Drawings Library dialog, as it appears in the 2016 release.
When adding files to the Styles Browser Content Drawings Library, instead of specifying individual files, you can specify a folder, and all of the files within that folder will be included in the library.
As always, you can click on an image to see it full size.

Once a folder is added, you can choose whether or not to include all of the files within any subfolders of that folder as well.
The big advantage here is not in saving a few clicks when setting up the Styles Browser Library (you can add multple source files in one operation), but that once a folder is selected, you can add a file to it at a later date and that file will be included in the Styles Browser Content Library automatically. That will save a lot of effort in a firm with more that a handful of users. One note of caution, including a large number of files in the Content Browser Content Library can result in slow performance as the Styles Browser generates preview images. That applies whether or not you are adding folders, but, particularly with the subfolders option checked, it is easier to add a lot of files, perhaps without even realizing it.

Object Type List Auto Scroll
In 2016, when working in the Object Type drop-down list, expanding a category at the bottom of the list did so, but you would then often need to scroll the list to see some or, in some cases, any of the items under the expanded category.
In 2017, when expanding a category at the bottom of the list, the list will automatically scroll to show the items in the expanded category.
A small, but welcome improvement for those making frequent use of the Styles Browser, particularly for MEP users, as they have more categories and the number of items in those categories is greater than the Multi-Purpose Objects category.

MEP Enhancements
  • Additional Objects: Panels, Devices, Schematic Symbols and Plumbing Fittings, which previously used the "old" Select Style dialog, are now integrated into the Styles Browser.
  • Additional Categories: The addition of the previously noted objects has prompted the replacement of the 2016 all-in-one MEP Objects category with five separate categories: Electrical Objects, HVAC Objects, Piping Objects, Plumbing Objects and Schematic Objects. These five categories remain grouped together, after Multi-Purpose Objects, rather than arranging all categories alphabetically, which would place Multi-Purpose Objects between HVAC Objects and Piping Objects.
  • All System Definitions are now selected in the Styles Browser, rather than the two methods used in 2015 (some objects in Styles Browser, some in the Select System dialog).
  • Routing Preferences for Conduit, Duct and Pipe have been added to the Styles Browser, and a single Routing Preferences content drawing has been provided with the out-of-the-box content as the source file. This will allow these routing preferences to be omitted from template files, and imported only as needed from the source file.

Closing Styles Browser
A new command, STYLESBROWSERCLOSE has been added to allow closing the Styles Browser from the command line. The Styles Browser ribbon tool (Home ribbon tab, Build panel, Tools split button drop-down list, Styles Browser tool) now toggles the display of the Styles Browser. If closed, the tool opens it; if open, the tool closes it. In 2016, the tool only opened the Styles Browser (and, if docked or auto-hidden, deployed it).

This Screencast demonstrates some of these new features, in AutoCAD Architecture.

April 20, 2016

Autodesk Answer Day

The next Autodesk® Answer Day will be on May 18, 2016, from 6:00 am to 6:00 pm U.S. Pacific Time. Unlike previous Answer Days, this one will not apply to just one featured software; Autodesk team members will be scouring the AutoCAD, AutoCAD Civil 3D, Revit, Inventor, Vault, Maya and 3ds Max forums.

Read more about the event here and mark your calendar.