Lurking EvilI use this term to describe items I know are going to crop up and challenge what may otherwise look like a feasible design. It lurks in the strangest places yet often stems from conflict with adjacent features, other new features developed in parallel or legacy Revit weirdness.
In the previous post custom elevation tags has a design and is moving forward. For those who keep track of Revit trivia the feature was born on 20090930_1159 (yyyymmdd_hhmm). After this date one could fire up a development build and test the feature out. It’s always desirable to get live code early in a release since problems are easier to witness than imagine. ….On to some of the issues:
Pre-2011 hard coded elevation tags were somewhat customizable as long as the built in properties could make a tag you liked. Properties controlled the shape of the tag, how pointy the arrows were, label presence, and label location. In the 2011 release we planned to ship new content that would match the old content yet this exposed some issues. Take the ‘View Name Position” property. Families do not have a property that controls text or label position. It would be silly since you can just place a label where you want but the hard coded elevation tags required a positional property. After some brainstorming it was decided that we could make a type for each possible combination of text and label location using visibility properties to turn them on and off. On upgrade we would map to the type that matched the existing condition. Sounds good yet the “Text Position”, “View Name Position”, “Reference Label Position” and the “Show View Name” properties demanded 4 x 3 x 3 x 2 types! The fact that the pointyness of the arrows shifted the labels suggested infinite types were required! In the end we decided that we could not ensure the tags looked exactly the same after upgrade but we would ensure the same labels were present keeping drawings readable and accurate. It would be possible to correct the upgrade results manually if this were required.
Reloading ContentGiven the capability of loading elevation tag content what happens when elevations exist in the project and the new symbol is different than the original? How many ways can it be different? This scary issue was raised early so we got a leg up on many of the solutions before actual implementation. Here are the main cases and solutions:
- If the user desires to make cosmetic changes to the family they must edit the family and reload it into the project.
- The instance will update on reload without affecting views provided the direction and number of nested pointers is unchanged.
- Adding new arrows are OK as they do not instantiate a new view until checked.
- Line work and labels changes are remapped.
- If the new symbol arrows are in the same relative direction and quantity to the base family as the project elevation instance then the system will match the orientation of the new instance to that of the placed instance and remap the arrows in the old instance to the new instance in a clockwise fashion.
- If a new instance is the same as the original but has fewer arrows than any used arrows the new symbol will be considered incompatible. The user must place a new symbol and delete the old views.
- If the base and pointer arrows do not correlate in number or direction then switching type is disallowed. The new symbol will be considered incompatible. The user must place a new symbol and delete the old views.
- If the user deletes an elevation family and it is instantiated in the project a warning will be issued similar to the one shown below for a callout head family.
It turned out that when placing elevation tags the hunting behavior (where it identifies nearby walls) caused the system to rotate the tag. This caused the now possible asymmetrical tags to be rotated large amounts and look stupid. A new algorithm had to be created that would choose the arrow from the tag that caused the least rotation rather than always rotate to the top arrow. The existing behavior was impossible to know because all the original hard coded tags were symmetrical. Here is the issue before and after resolution:
Labels in our custom families did not have capability this before 2011. We decided to open up and expose this property. Now there is a “Fixed Rotation” property for all family text and labels the family category Elevation Marks A similar property is still needed for lines to get the section head behavior.
Those were the biggest issues. As you can see nothing is ever a simple as it seems on the surface but I have to admit solving these is half the fun. Design is a form of problem solving - there are always constraints. The end result is more rewarding having overcome these obstacles.