Window tag sequence past 199
Can you post a sample file that exhibits this sudden jump from 199 to 1100? Unless there are Windows already numbered 200 through 1099 hiding in the model (perhaps in one or more unplaced block definitions?), I can think of no reason for that jump.
As for why your new property does not show in tags and schedules, tags and schedules are not magic items that can sort out that you want your new property to show in them. You have to add that property as a column to the Schedule Table definition, and edit the view block used by the Schedule Tag's Multi-View Block so that the attribute that displays the property value is associated with the new property, rather than the old.
In order to avoid having to do all that work to get the new property to show in the Schedule Table and Schedule Tags, resolving the initial issue is the better way to go. (Assuming it can be resolved....)
Hi David,
I'm sorry, but if CAD isn't magic, then what's the point of anything?
So, I understand that there are several steps to getting property sets to work and for sure I missed a step somewhere. Here are some snippets of what I'm doing:
Screenshot A is of the windows giving me troubles. No there aren't 901 extra windows floating around anywhere in the file since the schedule only populates with the selected objects which would be the ones located on the plan. When I use the "renumber property set" to get the windows in sequence this is what it gave me.
Screenshot B is of the modifications I did in Stylemanager to get an alternate set definition counting 200 instead of 100.
Screenshot C is of the modification I did for the alternate schedule as well.
And screenshot D is the results....which did not change the tag or the new "First floor window schedule (2)".
So, per your comment, the Multi-View Block definition (the tag) also needs to be modified...which I tried to do but there were no options to change number properties. So, I may just have to number those last 4 windows manually...
It just seems odd that the number sequence for window tags only allows for 199 windows, which granted, it's a crap ton of windows for one house.
Thank you for the response.
KP
Accepted solution
CAD can do things that appear magical, but like all magic, there is a boatload of unseen work, sweat and tears to make that magic happen.
Some thoughts:
- Screenshots are nice, but without an actual file, I can only see and understand so much. For example, you made a new Property Set, WindowObjects (2). You made a new Schedule Table Style, First floor window schedule (2). Both, presumably, by copying the original items of similar name, without the " (2)" suffix on the name. In Screenshot C, you highlight the example value of 201 for the "NO." column, but that column shows the Property Set as being Window Objects. I cannot tell if that column refers to the original WindowObjects Property Set or the new WindowObjects (2) set. If I had the file, I could make that column wider and see which it was. If a Schedule Table created with that style shows the same values as your original Schedule Table, then it is probably referring to the WindowObjects Property Set.
- If you want a Property to be used in a Schedule Tag, do not put a space character in the name of the Property Set or the name of the Property. For example, change WindowObjects (2) to WindowObjects2.
- If you are only showing objects you select in the Schedule Table, how do you know that there are not 901 other Windows in the file. There also does not have to be 901 other Windows. If you place 199 Windows numbered 1-199, then somehow introduce a Window with a Number property value of 1099, when you add another Window with the Number property, it will be numbered 1100. Auto-increment does not look for gaps in numbering, just the current highest value.
- The Auto-Increment properties only do the "auto-increment" thing when the property is initially added to an object, finding the highest current value and going to the next value. After the value is assigned, you can change it to anything you want, including numbers that are already assigned. If the problem here is that you somehow got Windows numbered 197, 198, 199, 1100, and 1101, just manually change 1100 and 1101 to 200 and 201 respectively and move on. It is not worth the time to create a new Property Set, a new Schedule Tag and a new Schedule Table Style for two tags that somehow picked up unwanted numbers.
- I cannot believe that the Renumber Data Tool (PROPERTYRENUMBERDATA command) renumbered 199 Windows 1 through 199 and then suddenly jumped to 1100 for the 200th Window when done all in one operation. Up until this time, however, I had never tried to renumber that many objects in one operation, so before stating my disbelief, I created a test file with 320 tagged Windows, using out-of-the-box US Imperial content. I selected all of the Windows and, in the Properties palette, on the Extended Data tab, changed the Number property value of all of them to 1. Then I fired up the Renumber Data tool, set the target Property Set to WindowObjects, the target Property to Number and accepted the defaults of the start number and increment both set to 1. I selected all 320 Windows, one-by-one, and got Windows numbered from 1 to 320.
- Schedule Tags are "special" Multi-View Blocks. AutoCAD Architecture recognizes a Multi-View Block as a Schedule Tag if it has at least one View Block (an ordinary AutoCAD Block Definition) assigned that includes at least one Attribute Definition whose Tag value is formatted like this: PropertySetName:PropertyName. Substitute the name of your Property Set for PropertySetName and the name of the Property whose value is to be displayed for PropertyName. Separate the two with a colon (:). For example, the out-of-the-box US Imperial Aec6_Window_Tag Multi-View Block Definition has one View Block assigned, to the Top View Direction of the General Display Representation, called Aec6_Window_Tag_P. That View Block has two Attribute Definitions, with Tag values of WINDOWOBJECTS:NUMBER and WINDOWSTYLES:TYPE. The first displays the value of the WindowObjects Number Property in the Tag. The other is an invisible attribute, so it does not display anything when the Tag is placed, but is there so that the WindowStyles Property Set is added to the Style of the tagged Window if it is not there already.
- Not sure how you got your Number property in the WindowObjects (2) Property Set to have a default value of 1 (the first number that will be used if there are no Windows with that Property attached in the file) and an Example of 201, unless it has something to do with your Number - Object (FP 2) Property Data Format. If you are adding prefixes or otherwise doing something in the Property Data Format that varies from the out-of-the-box Standard or Number - Object Property Data Formats, that may contribute to any unexpected renumbering issues.
In fact, I believe that may explain why your numbering is the way it is. Let me guess - you made a copy of the Number - Object property set, which zero pads integer values to have a minimum of two digits (1 becomes 01, 2 becomes 02, ... 9 becomes 09, and then the zero padding is ignored for integers 10 and higher). Then you decided that your first Window number should be 101, so you added a prefix of 1. That works just fine until you go beyond Window 99 (which becomes 199). Window 100 then becomes 1100, because that is what you told it to do - add a prefix of "1" to the value. If you just want your windows to start with 101, use the Standard Property Data format and set the Default value of the WindowObjects:Number property to 101. No special Property Data Format required, and you can have a Window number of 200.