December 30, 2004
December 24, 2004
As before, the schedule is sorted first by the room number and then by the ScheduleSortingOrder property, which this time is style-based, in the AllStyles Property Set Definition. That way the sorting number needs only to be assigned once to each Multi-View Block definition and the data is there for all instances. The header row blocks are again assigned a sorting order of 1. Power devices are assigned numbers starting with 11, switches start at 21 and teledata items start at 41. This groups like items together and allows for adding additional devices of a given type later. Obviously, if you were implementing this in the "real world", you would want to work out all the devices you would ever want to schedule, determine the order in which you would want to list them and assign sorting order numbers accordingly.
I made use of a formula property to give the header rows the MTEXT new line code to increase their height as I suggested could be done in the unit spaces post. This property is in the AllStyles Property Set Defintion. I did find that simply returning a value of "\P" in the formula did not work - I added a space character before and after new line code and it worked fine: " \P ".
For this schedule, listing each device separately was not desired, so a quantity column was added. I did not anticipate that the header rows would also get a quantity, and since that column is generated by the program, I can not suppress these. I am not happy with that, and, if this were not just a sample file, I would probably consider making the room number column visible and removing the header rows altogether.
Note also that for this sample, all I listed was the quantity and the Multi-View Block name. Additional properties could be added as columns so long as all devices of the same type display the same information, to keep them all on one line. If you do not want to use the Multi-View Block name as the device name, you can set up a manual property in the AllStyles Property Set Definition to hold the "display name" for each device. Substitute that property for the AllStyles:StyleName reference in the DeviceNameSchedule property in the BlockObjects Property Set Definition to get the manual property to display instead of the block name.
December 22, 2004
The clustering and ordering within each cluster is achieved by including two hidden columns in the Schedule Table Style. The first sort is done on the RoomNumber property, and the second sort is done on the OrderWithinUnit property. Both are manual properties that the user needs to fill in. The OrderWithinUnit property is also used to identify the space that forms the "header row" - it must always be set to 1. A formula property concatenates the unit room name and room number for the "header row" while passing through just the room name for the other spaces. Formula properties are used to process automatic properties in the table, clearing the values on the header row and passing through the values for the individual spaces within each unit. The remarks manual property is scheduled directly.
The sample also demonstrates that the header row can be made visually distinct by entering the MTEXT code "\P" [without the quotes] to force a new line, increasing the height of the header rows. The "\P" code will work even if it is in a hidden column, which might be preferable if it was desired to include actual remarks in the "header row". By using a formula property that returns a RESULT of "\P" if the OrderWithinUnit property is 1 and "" otherwise, adding that property to the schedule and hiding that column, you could prevent accidental erasure of the code on the "header row".
December 21, 2004
You would then use the formula property in your schedule [or tag], and the result displayed will be, in this case, the style-based manual property if the object-based override property is left at its default value, a null string. If the override property is not a null string, the override string is returned. The sample file includes a schedule table that displays all of the property data attached so you can see the effects of various combinations.
If you want to override a numeric value with another numeric value, I would suggest making the default value for the override property the number zero --> 0 <-- rather than a null string.
December 16, 2004
In the Page Setup dialog, the plot style file specified in the source file remains, but is noted as "missing". At least the default plot style file is not substituted, which would leave anyone opening the exported file completely unaware that a change had been made.
I now have a profile set up that is similar to the STB default one I generally use, but which has CTB as the default plot style type, for occasions where I need to export CTB files.
I am happy to report that ADT 2005 does not change the plot style type of a file being exported to AutoCAD 2000, even if the default plot style type is different from the plot style type of the drawing being exported. This is yet another reason to upgrade, or to install ADT2005 from that disk in the box on the shelf.
December 11, 2004
http://www.paulaubin.com/Public/AU_2004.atc . You can read more about this catalog in the Didn't get a chance to show this at AU thread in the Autodesk Archtitectural Desktop 2005 Discussion Group. I found the AU Logo Curtain Wall Style particularly interesting, and managed to reverse engineer it, with a little help from Paul.
Understanding the tool palettes is a must for anyone using Autodesk Architectural Desktop 2004 or 2005, as much of the out-of-the-box content is organized around having the typical ADT user view the tool palettes as the "one stop shopping" location for content. Paul's class provided a good overview of the basics and his handout went into even greater detail. If you get the chance to attend a future Autodesk University, you can not go wrong taking any course offered by Paul.
December 06, 2004
My only minor disappointment was the lack of intermediate to advanced level courses. I took a few classes that dealt with customizations involving programming that were a bit over my head, but most of the ADT classes were targeted primarily at the novice user. I fully understand the need to appeal to as broad an audience as possible - if insufficient numbers sign up for a class, it may be cancelled or, at the least, not be considered for the following year - but if return visits to Autodesk University are to be encouraged, there need to be courses that will engage the intermediate to advanced user, too.
I will try to find time to post gems from the courses I took, once I get caught up at work and at home.
November 28, 2004
November 26, 2004
Here's an ingenious partial solution to a somewhat vexing problem, how to deal with endcaps with wrapping materials for variable width walls, called to my attention by Terence Chatfield in the ADT 2005 Discussion Group thread My (evolving) Wish List.
If you have the same material on both sides being wrapped around the end, you can cover a range of widths with one endcap by making the wrapping polylines overlap for the full width between the components, rather than having only one reach across to the other. That way you can double the width between them and still be covered. Depending upon the expected range of the variable component, you may be able to have one, two or maybe three endcap styles, rather than one for every anticipated width.
November 25, 2004
The key to both issues is in the attribute tag names included with your ADT tag. But first, a brief overview of how tags a constructed. An ADT tag is a Multi-View Block [MVB] that has been turned into a "Custom Command" type of AEC Content file, using the AEC Content Wizard. The _AecAnnoScheduleTagAdd command attaches the MVB to an object with a tag anchor. The MVB is composed of one or more "view blocks". Each view block is an ordinary AutoCAD block, containing regular graphics [if desired] along with at least one attribute definition. It is the attribute tag name of this/these attribute[s] that we will focus on here.
ADT tags display one or more properties from one or more PSDs that are attached to an object. It is important to understand this distinction: the property value resides on the object, NOT in the attribute - the attribute merely is the vehicle for displaying the property value. You tell ADT which property to display by formatting the attribute tag name as follows:
where [PropertySetDefinitionName] is the name of your PSD and [PropertyName] is the name of a property within that PSD that is to be displayed by that attribute. For example, to display the Name property of the RoomObjects PSD, the attribute tag name would be ROOMOBJECTS:NAME.
ADT determines to which object types a particular tag may be applied by looking at the PSDs referenced by the attribute definitions contained within the view blocks attached to the MVB tag, and then looking at the object types to which those PSDs apply. For example, the "Room Tag" AEC Content file provided with ADT 2005 uses a MVB called "Aec3_Room_Tag", which has one view block, called "Aec3_Room_Tag_P". That view block, in turn, has three attribute definitions: ROOMOBJECTS:NAME, ROOMOBJECTS:NUMBER and SPACEOBJECTS:HEIGHT. The RoomObjects and SpaceObjects PSDs both apply to "Area, Space", so ADT will allow you to apply the tag to an area or a space, but not to any other objects. [As an aside, the "Room Tag" AEC Content file provided with ADT 2005 actually references the SPACESTYLES:HEIGHT property in the third attribute, but the out-of-the-block template files include a revised block definition for the "Aec3_Room_Tag_P" view block that changes that to SPACEOBJECTS:HEIGHT. This reflects the difference in property locations between ADT 3, when this tag was made, and ADT 2004/2005. If you are using ADT 2004 or 2005 and want to use this tag in a file that does not have the revised "Aec3_Room_Tag_P" definition in it, you may want to edit the content file and change the tag for that third attribute definition to SPACEOBJECTS:HEIGHT so that the SpaceObjects PSD is attached.]
The "Room Tag" also includes an example of how to get additional PSDs attached when tagging. If you have ever used this tag, you will have noticed that the tag does not display a "height". Take a look at the properties of the SPACEOBJECTS:HEIGHT attribute definition:
ATTRIBUTE Layer: "0"
Space: Model space
Handle = 1c61
Style = "Standard"
Font file = txt
center point, X= 8'-1" Y=3'-3 7/32" Z= 0'-0"
height 0'-0 1/2"
rotation angle 0.00
width scale factor 1.00000
obliquing angle 0.00
Notice, in particular the flags setting - "invisible". By including an invisible attribute definition that references a property in the PSD you wish to have attached to the object when you tag it, the tag will attach that PSD without displaying any of that PSDs values.
If you are just starting to tackle customizing ADT tags, you may want to take a look at two "Brain Dumps" written by Matt Dillon: "Schedule Basics" and "Creating Custom Automatic Schedule Tags". These were written for ADT 2, but will still give you a firm understanding of the relationships between PSDs, objects, tags and schedules. These are where I got my start. You can find a link to this in Chris Yanchar's "Between the Walls" ADT Weblog at the link below. Chris' Weblog is a great resource for information on ADT.
Having what I assume to be a typical architect's schedule, I make no promises as to the volume or regularity of the postings here, but I do hope to use this as a catalyst to get me to consolidate my own "knowledge base" on ADT and to serve as the incubator for tutorials and classes for others at the firm where I work and perhaps other outlets as well. If all goes well, I want to take advantage of the Thanksgiving holiday to get some content posted prior to shipping out to Autodesk University on November 29. If you are attending Autodesk University this year, stop by booth 511 (at the back, on the left) during the AUGI Beer Bust on Tuesday night to learn more about the discussion groups. You might even run into me.
Click on this link to get to the Autodesk Discussion Group Main Index Page.