Which Door Tag Should I Use?

There are three different doors tags provided in the out-of-the-box content for ADT 2004 and 2005. If you have been confused about how they work, which one to use, or how you might adapt a project-based tag for a non-project file, read on.

The "Door Tag" tag is equivalent to the one that shipped with releases prior to ADT 2004. It displays the value of the DOOROBJECTS:NUMBER property, which, out-of-the-box, is a manual, auto-incrementing integer using the Number - Object Property Data Format, so your door numbers would be 01, 02, 03, etc. You can edit the values after the fact, but the new value must be an integer. This works fine, as is, for any file [with less than 99 doors], although you may want to consider the project-based tags, depending upon your door identification needs.

The "Door Tag - Project Based" and "Door Tag - Project Based - Scale Dependent" tags are designed to work with the Drawing Management features introduced in ADT 2004 [Project Browser/Project Navigator]. Both display two properties: DOOROBJECTS:ROOMNUMBER on top and DOOROBJECTS:NUMBERSUFFIX on the bottom. The main difference between the two is that the "Scale Dependent" version inserts a Multi-View Block at a scale factor of 1, while the other uses annotation scaling. The "Scale Dependent" tag has three view blocks attached to three different Display Representations; each is scaled so that it is sized "correctly" for the out-of-the-box Low Detail, Medium Detail and High Detail Display Configurations, corresponding to the Imperial Scales of 1/16" = 1'-0", 1/8" = 1'-0" and 1/4" = 1'-0". I assume the metric tag also works in a similar fashion, for 1:200, 1:100 and 1:50, but I have not used it and can not say for certain. So if you want the same tag to display at multiple scales, the "Scale Dependent" version may suit your needs. If you often work at other scales, or only at one scale, then the non-scale-dependent version may be better.

The DOOROBJECTS:ROOMNUMBER property, in the out-of-the-box Property Set Definition, is a Location property, and it "reads" the ROOMOBJECTS:NUMBERPROJECTBASED property from the Space object found by the location grip of the door. The ROOMOBJECTS:NUMBERPROJECTBASED property is a concatenation of the space's ROOMOBJECTS:LEVEL [a Project property that reads the level assigned to the Construct in which the space resides] and ROOMOBJECTS:INCREMENT properties [a manual auto-increment integer property]. This is why these tags work only in a project environment - the LEVEL property has no useful value otherwise.

The DOOROBJECTS:NUMBERSUFFIX property is a manual text property that you fill in for each door [default value is "A"] and is used to distiguish between doors when one room has more than one door opening, since the number portion of the door identification is the room number.

If you are not using Project Navigator, but like the way the project-based tags work, fear not, you can easily modify the DoorObjects Property Set Definition to make these tags work in a non-project environment. Assuming that you are using the ROOMOBJECTS:NUMBER property for your room numbers, edit the Door Objects Property Set Definition, highlight the RoomNumber property on the Definition tab, and select the Edit Location... button at the lower left. Change the property being read from ROOMOBJECTS:NUMBERPROJECTBASED to ROOMOBJECTS:NUMBER and it will read your non-project-based room number and you can use the project-based tags.

You will need to make that change to the PropertySetDefs.dwg file located in the folder just above the tags if you want all future drawings to work that way, and use the Style Manager to copy the revised version to any existing drawings, choosing to overwrite the current version, for any files that already have the old DoorObjects Property Set Definition in them. If you are doing any additional customization to the tags and/or these Property Set Definitions, I would strongly recommend setting up a separate Property Set Definition source file with a unique name, and renaming your Property Set Defintions. This will avoid future confusion with files that have the out-of-the-box definitions in them and will also make it easier to migrate to future versions, as you will not need to remember or meticulously document all of the changes you made to the out-of-the-box content. It does mean that you will need to edit the view blocks so that their attributes reference your custom Property Set Definition and edit the AEC Content files, so that the correct source file is indicated in the Command String. Unless the only change you make is to the source for the Location property, I think it is worth the effort to set up separate files/definitions for your customizations.