Classification Definitions have been around since Autodesk® Architectural Desktop 2004. One use for them is to act as an additional filter for the AEC objects that can be included in a Schedule Table; unlike layer filters, Classification Definition filters can be built right into the Schedule Table Style, on the Applies To tab. You can also use them on Property Set Definitions to limit the objects to which you can attach a Property Set.
I have been using them to control what objects are seen in Schedule Tables for quite some time now. A recent thread in the AutoCAD® Architecture General Discussion Group had me wondering if they could be used to prevent a Schedule Tag from being placed on an item, theorizing that if a Classification Definition was set up such that the Property Sets referenced by the Schedule Tag did not apply to a particular object, perhaps I would be unable to tag that object.
To test my hypothesis, in the 2016 release, I created a Classification Definition called Schedule that applies to all objects, with two Classifications: Schedule and No Schedule.
I then applied this Classification Definition to the Property Set Definitions referenced by the out-of-the-box US Imperial Door Tag (non-project), classifying each as Schedule.
Finally, I applied the Classification Definition to the Door Styles, on the Classifications tab of each style. In my test file, the Hinged - Single, Hinged - Double and Sliding - Double - Full Lite Door Styles were set to Schedule, and the Cased Opening Door Style was set to No Schedule.
I placed a few instances of the Doors (two of the Cased Opening style, one each of the others). On the Extended Data tab of the Properties palette, I observed that the Add Property Sets button was grayed out for the Cased Opening Doors, as it should be, since the DoorObjects Property Set does not apply due to the classification being set to No Schedule for those Doors. I edited the Cased Opening Door Style, and, on the General Tab, selected the Property Sets button and manually removed the FrameStyles, DoorStyles and ManufacturerStyles Property Sets (which were attached in the source file). Once I did so, the Add Property Sets remained grayed out, due to the classification.
At this point, I used the out-of-the-box US Imperial Door Tag tool (Document tool palette group, Tags palette) and attempted to tag each of the doors. As you can see in the image below, I was not prevented from tagging the Cased Opening Doors, even though none of the referenced Property Sets could be applied to those Doors. I did get a Command line message stating: Note: Not all properties apply to selected object. The DoorObjects Property Set was not applied to these Doors, and the Schedule Tag displayed the default value assigned to the attribute definition in the tag's view block. Surprisingly, the style-based Property Sets were attached to the Cased Opening Door Style, even though those did not apply, either.
In the image above, I turned on the display of the Anchor Extended Tag to Entity component, and set its color to green. The green arcs extending from the Schedule Tag insertion point to the Door origin point are these anchor components, verifying that the Tags on the Cased Opening Doors are in fact anchored. I also repeated this experiment, with a custom Schedule Tag that only referenced one object-based Property Set, but the Cased Opening Doors still received the tag, even though the referenced Property Set was not attached. Similar results were obtained in the 2015 release as well.
So, using a Classification filter to limit the objects to which Property Set Definitions apply will not prevent a Schedule Tag that references properties in such a Property Set Definition from being anchored, and will even add any style-based Property Sets referenced by the Schedule Tag. Object-based Property Sets will not be attached, and attributes that are set up to display the value of object-based properties will only show the default attribute value.
No comments:
Post a Comment