Glazed Doors in Window and Door Schedules in Revit

I started out writing this blog post about the behaviour of subcategories in nested families.  On closer investigation, the weird behaviour I intended documenting was not as I had thought - still a bit strange but not quite worthy of a post all to itself.  So I have changed tack and turned it into a discussion about how to get a glazed door family to appear in both door and window schedules.  Many experienced Revit users should already know this, but for those who do not, read on.

Schedules and Categories

Typically door and window schedules are created separately as single category schedules. Multi-category schedules have too many limitations to make them work efficiently for this task. A door or a window is usually either one of those categories, and therefore it can only appear in one of the schedules.  What if you have a window assembly that contains a glazed door? or a sliding glass door, which you want to show in the window schedule (because it is glazing), but also in the door schedule (because it hosts door hardware)?  This common requirement seems problematic in Revit, but there is a way around it . . .

Workaround:

Shared Nested Family

When a nested family is 'Shared', it behaves differently to the parent family in terms of subcategories.
For example, you might have a window parent family, that contains just a frame (or a fixed glass side panel).  Inside this could be a nested sliding door family.  Providing the door family is set to 'Shared', then it can have its subcategories independently controlled (by View Visibility) in the project;  it can also be individually selected, tagged and scheduled (as a door); the parent family can be tagged and scheduled as a window.

Nested Door Family Category Settings

Nested Door Family Subcategory

Parent Window Family

Parent Family Category

Parent Family Subcategories

Nested Door Family in Parent Family

Tagging and Schedules

Standard door and window families are normally tagged separately according to category

Once placed in a project, the combined door/window family can be tagged for either category:

Tag the whole family for the window category tag

Tab select the nested door family to tag it

Scheduling

• The combined window/door family will appear in a window schedule. 
• The Nested door family will appear in a door schedule

Category Visibility

This example shows a single swing door nested family in a window family (with fixed window panels either side).  In the project, both door and window categories/subcategories affect the sub-element display:

All Categories On

Door Panel Subcategory Off

Window Category Off - Door Category On

Non-shared Nested Family Categories

When a normal 'non-shared' family of one category is nested inside another family of a different category, it behaves as if it is part of the parent family in terms of categories.

Unshared Family Settings

In the parent family (in Family Editor), the nested family still shows its category when selected

Non-Shared Nested Door Family in Window Parent Family

When loaded into a project the whole window can be selected, but not the nested door family. 

Window family with non-shared nested door - in project

Changing the visibility of the Door category does not affect the nested door.

Door Category Off, Window Category Visible

Hiding the Window category, (while the door category is visible) hides the whole family, including the nested door

Door Category Visible, Window Category Off

This behaviour is as expected.

Weird Revit Behaviour:

Non-Shared Nested Families

However, if the nested families have elements of a specific subcategory (of the Nested family category - door) the element's visibility is still controlled by that nested family subcategory.  This does not really make sense if the nested family is not shared.

Door Panel Subcategory Off

This can be very confusing, as you have no way of knowing what category the nested family is, without editing the parent family.  As far as the user is concerned, the family is a window - since you cannot select the nested door in the project, the user will not be aware that it even has a nested family, let alone that a subcategory that has nothing to do with windows will still affect it.

Revit Rough Width/Height System Parameters

Making use of the Revit Rough Width and Rough Height System Parameters for Doors and Windows

Having heard lots of questions about how to control or remove the "Rough" system parameters, I thought I'd share a couple of tips I figured out for making them more useful.

Revit door and window templates provide several system parameters that cannot be deleted or renamed.  They are also Type parameters by default, which may not suit your purpose:

1. Width
2. Height
3. Rough Width
4. Rough Height

A lot of people don't use the "Rough" parameters, as the Width and Height are sufficient.  Here is a way to put the redundant system parameters to use:

Let's suppose that the overall sizes of your window families are controlled by type parameters Width and Height.  Most people have a naming convention for the windows that include the sizes in the name - eg.  WN_1800x1200
There is always a chance that a user will duplicate a type and name it wrongly, or make a mistake so that the name does not match the actual size.  This can be annoying or even dangerous if someone makes an assumption about the size without checking (which involves going into the Type properties dialog box).

There is a simple way to make it much easier to check on the fly.  Add a couple of basic formulas to the Rough parameters

• Rough Width = Width
• Rough Height = Height

Type to Instance

Now we want those Rough parameters to be instance parameters, but apparently you can't change them as the "Modify" icon is grayed out when you select one

• Go back to the plan view and select the Width dimension;  
• change it to "Rough Width";
• Check the "Instance Parameter" box in the options bar;
• Change the dimension back to the Width parameter;

Repeat this operation for the Height dimension in the front elevation view;

When you load the family into a project and place a window, the window instance properties will display the size (Rough Width and Height), but they will be grayed out so you can't change the size without going into the type properties.

Its a simple but effective way to make use of those annoying redundant system parameters.   It also shows an easy way to change system parameters from type to instance in the family.