ACA-AMEP 2018: ByLayer Values in Objects in External References

5/30/2017 UPDATE:
On 5/26/2017, AutoCAD^® Architecture 2018.0.1 Update and AutoCAD^® MEP 2018.0.1 Update (in both 32-bit and 64-bit versions) were released, and are supposed to resolve this issue. I have not yet had an opportunity to install this to verify. You can read the full release notes here.

There is a bug in the 2018 release of AutoCAD^® Architecture and AutoCAD^® MEP that affects how the "ByLayer" property value of an AEC object in an external reference is being resolved. If a component is assigned to Layer 0 and then the Color, Linetype, Lineweight, Plot Style, etc. is set to ByLayer, the value assigned to the layer of the parent AEC object should be assigned. When the object is directly in the current file, that works. But if that file is externally referenced into another file, the property value of the layer of the external reference is assigned, rather than the property value of the layer of the parent AEC object. In the image below, the left side shows a Door that has been placed on a layer called A-Door-Demo. The visible components are assigned to Layer 0, with ByLayer Color and Linetype. Layer A-Door-Demo has Color set to 32 and Linetype set to HIDDEN2. On the right side, that file has been externally referenced into another file, and placed on a layer called A-Anno-Refr, which is set to Color 212 and Linetype Continuous. As you can see, the Door components have picked up the Color and Linetype from the layer on which the external reference is placed, not from the layer of the parent Door object.

The suggested workaround, changing "ByLayer" to "ByBlock" works, but would be a major undertaking if you have many components assigned to Layer 0 with ByLayer attributes. We will hold off on deploying 2018 until this is fixed.

As noted in this Autodesk Knowledge Network article, Autodesk is aware of the problem and working on a fix. Keep an eye on that article; I suspect that when a fix is released, the article will be updated to reflect that.

ACA/AMEP 2018: New Features Part 1 - External Reference Improvements

I usually start out my first "new features" article for a given release by remarking that I have been busy, and apologizing for the delay in preparing the article. While I am indeed busy this year as well, and that has contributed to the tardiness of this article, another contributing factor is my lack of enthusiasm over the lack of new AutoCAD^® Architecture and AutoCAD^® MEP features in the 2018 release. My understanding is that you all (meaning, all of you end users out there) have been telling Autodesk that you would rather have them fix things that need fixing in the existing features, rather than adding new features. While I like fixing bugs or adjusting the design of a feature to better suit typical industry workflows as much as the next person (maybe more so), in my mind most of that effort should be in the province of a service pack or hotfix, unless it truly is a major change from the original feature design and the original feature design more or less worked as designed. This is particularly upsetting given that the pain of a new file format is being inflicted, without any offsetting new features that required a new file format to implement.

So, a number of items that had been reported as not working as expected have been fixed. Support for 4k monitors has been integrated for AutoCAD Architecture and AutoCAD MEP dialogs, palettes, etc. (I do not have 4k monitors, so I am taking their word on that.) And, all of the wonderful new things added to the core AutoCAD feature set have been integrated into AutoCAD Architecture/MEP. The balance of this article will look at the improvements made to external references.

External Reference Improvements

• Relative path is the new default when attaching an externally referenced file to a drawing. Use the REFPATHTYPE System Variable to set a different default path type: 0 = No Path, 1 = Relative Path and 2 = Full Path.
• Use of a relative path for an externally referenced file no longer requires that the host file be named/saved. Instead, the full path will temporarily be shown in the Saved Path column, with a preceding "*" and, in the Details section, the Pending Relative Path property will show as "Yes". Once the file is saved, any pending relative paths will be resolved and show the relative path in lieu of the temporary full path.
  
• If you save a file to a new location and that file has relatively pathed external reference files attached, you will be prompted as to whether or not the relative paths should be updated for the new location. If you only plan to save this one file to the new location and you want the relatively pathed external references to be found, you will most likely want to update the relative paths. If you eventually intend to move (or copy) the relatively referenced files such that they will be in the same relative location, then not updating the paths may be the appropriate choice.
  
• There are two new right-click contextual menu choices when dealing with an externally referenced file that is "not found".
  
  • Select New Path: This option provides the opportunity to browse to a new location (path) for the "not found" file. If there are additional "not found" external references, you will be asked if the new path should be applied to those, as well.
    
  • Find and Replace: This option allows you to select one or more external references and then specify a target path (Find saved path) and specify a replacement path (Replace with). For ONLY the external references that were selected when you right clicked and chose Find and Replace, AutoCAD will look for any that have the target path and will replace that path with the replacement path.
    
    
    If all of the selected external references currently have the same path, that path will be offered as the initial default in the Find saved path edit box. If you select external references with different paths, you will have to supply both the Find and the Replace paths. Note that if you use the ellipsis button at the right side of either edit box, you will get the full path of the selected folder, regardless of the path type shown in the Find edit box, or the path type used for the selected external references. You can manually edit that path to be a relative path, if desired. If the external reference uses a relative path, providing the equivalent full path in the Find box will not result in a match. In limited testing, providing the full path as the Replace path for an external reference that is currently set to relative path did result in the relative equivalent to that full path being applied.
    
    Find and Replace also appears on the right click context menu when selecting "found" external references and can be used to repath multiple references at one time (provided that the current and replacement paths are the same for all selected external references). Note also that the text entered in both edit boxes has to be an actual path. You cannot just enter the text you want to replace in the Find edit box and the text that you want to substitute in the Replace edit box; the complete path must be used in both (whether a full path or a relative path).


• When right clicking on one or more selected references and using the Change Path Type context menu item, if all of the selected items currently have the same path type, that path type will be disabled in the cascading contextual submenu. If there are multiple path types in the selected references, then all three options will be enabled.
  
• The Open option right click context menu option is no longer disabled for unloaded external references.
  
• If you rename an unloaded external reference on the External References palette, it will no longer automatically be reloaded. You will need to reload the reference in a separate action if and when you want it reloaded. Note: As in previous versions, using the RENAME command, and the Rename dialog, to rename an unloaded external reference will leave the external reference unloaded. New in 2018, if you use the Rename dialog or the CLASSICXREF command's Xref Manager to rename an external reference, that change will show immediately in the Reference Manager palette, without the need to reload the renamed reference.
• There has also been a minor change to the dialog that appears when opening a drawing with external references that cannot be found. Instead of referring to these files as "missing", they are now noted as "Not Found". The text on the button that opens the Reference Manager has also been simplified.
  

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.

Location Property Misread

If you are experiencing Location properties not reading the correct property when working through external references, you may want to see if the problem is similar to one I recently experienced.

A project in my office was being done in ACA 2010, and was not using the Drawing Management (Project Browser/Project Navigator) feature. Space objects were placed in the main "model" file, and had the company standard Property Set attached which includes two Text-type Manual properties for the room name (for two separate lines, set up before attributes in the view block of a Multi-View Block tag could wrap text), a formula property to concatenate those two Manual properties, for use in Schedule Tables and a Manual room number property. The Property Set was an older version, which also has three "residual" properties from the out-of-the-box property set, a Project property for Level, an Integer-type Manual property for the room number "Increment" and a formula property to concatenate the Level and Increment properties. A separate Property Set was also attached to the Spaces to hold a project-specific Text-type Manual property to hold the "room code".

In order to allow additional staff to work simultaneously, the equipment for the project was placed in several different "equipment" files, which were then externally referenced into the main model file. The main model file was also externally referenced into the equipment files, so that the equipment could be located. The equipment had a Property Set that included three Location properties: one for the concatenated formula property for the room name, one for the room number and one for the room code.

There were a number of issues with the state of the files at the time I was consulted. Once I got the needed Property Sets attached, I found that the room code Location property read the information correctly, but the room name and room number properties were displaying *No Project* for a value. I double checked to make certain that the correct properties were being referenced, and that these did not make use of the Project property. All appeared to be set up correctly.

I finally discovered what the problem was (even if I do not understand why it was a problem) - the equipment drawings had our current version of the Property Set for room names and numbers, which no longer have the "residual" Project-based properties. For some reason, the fact that this was different from the version of the Property Set in the main model file caused ACA to become "confused" (no, that is not a technical term) and resulted in ACA grabbing the wrong property values from the main model. I discovered this when I added two more Location properties, referencing the two Manual properties that make up the room name. The Location property referencing the first line property also displayed *No Project*, but the Location property referencing the second line property was displaying the value of the first line property! At that point, I discovered that the Property Set in the equipment drawings was different from the one in the main model file. I did not want to take a chance on losing all of the values for the room names and numbers in the main model file, so I copied the version in that file to the equipment file, and, just like that, the Location properties started referencing the right properties.

So, if you are seeing a Location property in one file referencing the wrong property from a Space in an externally referenced file, one thing to check is whether the Property Set that has the Space property being referenced is identical in both files.

As part of my diagnostics, I opened the ACA 2010 files in both ACA 2011 and Release Candidate Beta 2012, and the problem occurred in those versions, also.

Searching for Files with a Specific External Reference

If you have ever wanted to know all of the files that include a particular external reference, but had to resort to opening every possible file and manually check it, you will want to read Lynn Allen's post on using DesignCenter to search files for external references.