ACA: Offset External References, Location Properties and Schedule Tags

If you have ever externally referenced several files into one host file, and had Schedule Tags placed within the externally referenced files that displayed property values that were from or based on Location properties, you may have found that in the host file, the Schedule Tags did not display the expected values. One common example would be the use of a Door Tag that displays an ID value for the Door that is based in part on the associated room number, with the room number value being brought into the Door's properties via a Location property.

Depending upon what version you are using and how you place the external references, you may find that the values displayed in the tags all display values from the Spaces of one of the external references, or that you get *Space not found* in lieu of the Space-based property value that the Location property is supposed to be reading and which shows as expected when the externally referenced file is opened directly.

Things worked as expected in ACA 2009 and earlier, but some change made in the 2010 release affected the way that Location-property-dependent values are displayed in tags nested (placed) in the files that are externally referenced. All of the examples shown in this article are done outside of the Drawing Management feature (Project Browser and Project Navigator). Because managing property data overrides is difficult outside of the Drawing Management feature, tags referencing object-based properties are usually placed directly in the file that holds the object being tagged. (My firm does it this way, and from recent posts in the Discussion Groups, it appears that others do as well.) Note also that a Schedule Table placed in the host file that is set to scan external references and which uses the external references for the selection set and applies to the same objects that are tagged by the nested Schedule Tags will display the expected values in all of the releases from 2010 through 2014; the issue is only with the values displayed by nested Schedule Tags. In all releases since 2010, it appears that nested Schedule Tags do not look for a Space from the effective location of the nested Location grip in the host file, but instead take the relative X- and Y-distances from the insertion point of the external reference to the Location grip, and then apply that X, Y coordinate relative to 0,0 in the host file and look there for a Space (or, if your Location references a property attached to an AEC Polygon, for an AEC Polygon). If it finds a Space, it reads the specified property from that Space. That works fine for one external reference, inserted at 0,0. But in a file where you are inserting several external references, you will likely not place all of the files at 0,0,0, since then it would be up to ACA to determine which of what would likely be several overlapping Spaces would be used. Assuming that each floor of the floors is above or below the others (and that they share a common 0,0 point), all of the floors would be reading values from the Spaces in the floor placed at 0,0,0.

The logical solution would be to not place any of the external references in the host file at 0,0,0 and to place then such that the building footprint relative to 0,0,0 is left open in the host file. Unfortunately, in the 2010 and 2011 releases, that results in the tags displaying *Space not found* in lieu of the expected Space-based property value. I apologize to anyone still using the 2012 release, as I do not have access to an installed version of that release, so I am not certain how that release behaves. In the 2013 and 2014 releases, a partial adjustment was made, and the tags will display the value they display directly in the external reference file, provided that there is no Space at the "mapped" location relative to 0,0 in the host file.

I have posted some sample files, in the Door tag incorrectl​y finding informatio​n from other floors thread in the Autodesk AutoCAD^® Architecture General Discussion Group, based on the "Room" shown in the image above, so that you can see the effects firsthand. There are three "floor" files, for the First, Second and Third floors, and a "sheet" file into which the three floor files are externally referenced. Each floor file has a single Space onto which two doors open. The files include a modified version of out-of-the-box DoorObjects Property Set Definition, in which two new properties have been added: RoomNumberNonProjectBased is a Location property, referencing the SpaceObjects:Number property attached to the Space; NumberRoomBased is a Formula property that concatenates the RoomNumberNonProjectBased property, a period (".") and the NumberSuffix property. The left-side doors have a NumberSuffix value of "1"; the right-side doors have a value of "2". The sheet file has a modified version of the out-of-the-box Door Schedule, with the MARK column deleted and replaced by a DOOR ID column, displaying the value of the NumberRoomBased property. The Doors are tagged in each floor file with a custom Schedule Tag that also references the NumberRoomBased property. The files were created in ACA 2010, so that they can be opened in that release or any later release.

The image below is of the sheet file, opened in 2010. None of the externally referenced floor files is inserted at 0,0, and there are no Spaces below the "mapped" location of the Location grips of the Doors.

Notice that the DOOR ID column in the schedule table correctly shows the values on all three floors, yet, as shown in the enlargement of the Second Floor external reference, the Schedule Tags inside the plan external references, which tag the doors, show *SPACE NOT FOUND* instead of the room number.

If the First Floor external reference is moved so that its insertion point is at 0,0,0 and the model is regenerated, then the nested Schedule Tags on the Doors on all three external references read the room number from the First Floor external reference. The Schedule Table continues to show the correct values, as seen in the image below.

If the First Floor external reference is moved back to its previous location, away from 0,0,0, and two Spaces (ROOM 5555 and ROOM 6666) are drawn in the host file, one at each mapped location and the model is regenerated, then the nested Schedule Tags on the Doors on all three external references will read the corresponding room numbers (5555 and 6666), but the Schedule Table will show the correct values, as shown in the image below.

Opening the same files in 2013 or 2014 will give the same results, with the exception of the first sheet view image above, where instead of *SPACE NOT FOUND*, the desired room numbers will be displayed on all three floor plans, because there is no Space in the "mapped" location.

Dealing With "*Xxx not found*" Location Property Result

Update for 2007 and later:
Change the formula properties in the examples below (or in the sample file downloaded from the Discussion Group) to test for "*Space not found*", rather than "*Area not found*". Area objects were merged into the new-and-improved Space object in 2007, so opening the sample file in 2007 or later will convert the Area objects in the sample file to Space objects, and the "not found" return value will change to "*Space not found*".

A location property will return *Xxx not found*, where Xxx is Space, Area or AEC Polygon, if the location grip for the object to which the location property is attached can not find an object of the type specified in the location property. This value is not a string - the VBScript TypeName and VarType functions crash when evaluating this value, so I have no idea what it actually is.

A denizen of the Autodesk Architectural Desktop Discussion Group posted a request for a method of dealing with this return value. The situation was one where a location property was being used with Areas, so that, where appropriate, a subordinate Area's area could be read into the main Area's properties and shown on a schedule. There would be main Areas, however, that would not have subordinate Areas; these would get the dreaded *Area not found* in the Location property and seing that in the schedule was not acceptable. When writing a Formula property to return "-" when there was no subordinate Area, the formula crashed when trying to compare the Location property value to *Area not found*. I have posted a sample file, done in ADT 2004, in a reply to that thread, that addresses the issued raised and also shows how you can create a Formula property from the Location that has a real number value with which calculations can be done. In the "not found" case, the real number is set to zero. Please note that the sample file was created to show possibilities, and the properties included are not optimized to a specific need. Some of the "formatted" properties would not be needed if the values were not being displayed in a Schedule Tag, as the "Unformmated" version could be placed as a column in a Schedule Table Style and a Property Data Format applied there. Some of the Formula properties might also be combined if there were no need for the intermediate results. Also note that the sample file was done in imperial units; the same concepts should apply to metric unit drawings as well.The image above shows the test objects in my sample file. There are three Area objects, two ten-foot square Areas, Living Room 100 and Bedroom 101, and a fifteen square foot Area for Balcony 101A. As you can see, Balcony 101A is subordinate to Living Room 100, as the Living Room Area's location grip is positioned over the Balcony Area. Neither the Balcony nor the Bedroom have a subordinate Area. For scheduling purposes, I created a Classification Definition that applies to Area objects, with two classifications - Main and Subordinate. The Living Room and Bedroom objects use an Area Style that has been classified as Main; the Balcony's Area Style is classified as Subordinate. This makes including only Main Areas in a Schedule Table easy, even if the Schedule Table is not in the same file as the Areas.

Writing an if condition to test the value of the Location property is fairly easy. Simply enclose the Location property and the test phrase in double quotation marks, and VBScript will do a text comparison. The problem is how to return the Location property value when an Area is found in a usable data format. You can not pass through the "raw" Location property value, as VBScript evaluates the entire formula, not just the logical path followed for each object, and *Area not found* will result in an error for Areas with no subordinate area. If the only need is a string which can be displayed in a Schedule Table, the solution is easy and the same as that for the if condition - enclose the property in double quotation marks. In the sample file, I have two location properties - SubordinateAreaFormatted and SubordinateAreaUnformatted. Both reference the BaseAreaUnformatted property of the subordinate Area; the formatted version uses the out-of-the-box Area Property Data Format; the unformatted version uses a custom Property Data Format called Standard-8, which is a copy of the Standard Property Data Format with the precision set to eight decimal places to maintain maximum precision, and, in this case, no zero suppression. The SubordinateAreaModified01 Formula property uses these two properties to test for "*Area not found*" and return "-" if found or the SubordinateAreaFormatted property as a string if an area is found. The formula is shown below:

If "[SubordinateAreaUnformatted]" = "*Area not found*" Then
 RESULT = "-"
Else
 RESULT = "[SubordinateAreaFormatted]"
End If

This property can then be added to a Schedule Table, as shown below:
That is all well and fine if all you want to do is display the subordinate area in a Schedule Table. But what if you wanted to be able to have the Area as a numeric value, with which you could do some calculation? The same limitations encountered above will apply, and the solution used in the sample file is to accept that the Location property will have to be converted to a string to avoid an error in the formula, then to take that string and convert it into real number. In the sample file, this is handled by two separate Formula properties; you could easily combine them into one Formula property that does it all. The SubordinateAreaModified02 Formula property looks remarkably similar to the previous one, with the exception that the result when an Area is not found is "0.0" rather than "-" and the unformatted Location property is used. That is because we want to convert these values to real numbers, and non-numeric characters will cause an error.

If "[SubordinateAreaUnformatted]" = "*Area not found*" Then
 RESULT = "0.0"
Else
 RESULT = "[SubordinateAreaUnformatted]"
End If

The text values of the property would appear like the image below, if it were added to a Schedule Table.

The SubordinateAreaReal Formula property takes the value of the SubordinateAreaModified02 Formula property and uses the CDbl function to convert the strings to real numbers. Be aware that if you pass a string that contains any non numeric characters, other than an initial minus sign or a decimal point, using CDbl will result in an error. That is why the unformatted version of the Location value is used in the SubordinateAreaModified02 Formula property. The image below shows this property in a Schedule Table.

CDbl ( [SubordinateAreaModified02] )

A combined Formula property, not included in the sample file, might look something like this:

If "[SubordinateAreaUnformatted]" = "*Area not found*" Then
 RESULT = 0.0
Else
 RESULT = CDbl( "[SubordinateAreaUnformatted]" )
End If

Now that we have a real number value, we can do math! [Trust me, that is a good thing.] Suppose that for rental purposes, the area of the balcony gets included at 75% of its actual area, along with the main area. The TotalAreaUnformatted Formula property is a simple, one-line calculation that does just that, and leaves the result unformatted should there be a need to do further mathematical operations on the result.

[BaseAreaUnformatted] + ( 0.75 * [SubordinateAreaReal] )

The TotalAreaFormatted Formula property simply passes through the value of the TotalAreaUnformatted property, applying the Area Property Data Format to it. If you are not going to include this value in a Schedule Tag, you could omit this property and use the TotalAreaUnformatted value as a column in your Schedule Table Style, changing the Property Data Format for the column to Area. The image below shows the formatted value in a Schedule Table.

You can click on the image below to see a larger version of the entire table, with some explanatory text below each column, or download the sample file from the Discussion Group thread and look at it live.