Custom ID tags for windows and doors

[Christiaan]

We'd like custom ID tags for windows and doors.

 

One of the main reasons we need them is to display the fire-rating of doors on floor plans for instance.  

 

We used to use symbols for doors, including our own custom ID tag (linked to a record format), and this included a fire-rating field. But now that we're using the Door Object we don't have this capability. The fire-rating is there in the door data but we're unable to display it as part of the ID tag, because ID tags are limited to ID Prefix, ID Label and ID Suffix.

 

You might say that we could use the ID Suffix field to show the fire-rating but we already use this field to identify a door type (and the fire-rating is already has its own field). So a typical door number for us would look like this: D-09-B (D=door, 09=door number, and B=type)

 

WinDoor, for instance, has custom ID tags, which are symbols the user can edit. They also have a second field that you can use for any piece of data you like, such as the fire-rating.

 

 

 

See also:

https://forum.vectorworks.net/index.php?/topic/64381-window-and-door-tool-maturity/

 

Edited April 27, 2022 by Christiaan

[LarryO]

This is a classic case for BIM integration.

The information / data that everyone is referring to is stored in a record attached to the building object (in this case a door) not the display object (a tag).

The BIM data can then be accessible to worksheets and any variety of customizable tags (a plugin object which incorporates a user defined symbol with linked text and transfers data from the building object's record to the display object's record of fields).

 

One possibility is: the user creates their own page based symbol laying out the tag with text, linking each text to a field in an attached record. The symbols' field names match the field names contained within the record attached to the door object. If you don't want a particular piece of data in your custom tag you don't include that field name in your symbol's record. The tag creator also includes two additional fields in their symbol's record, one which utilizes a pre-defined (field) name that the Placement Tool identifies with which contains the name of the record or plugin object the Placement Tool would search for in the object ('door-record') you attempt to associate the tag with. And a second field which stores the unique 'serial' number of the door object (in this scenario). This serial number is essentially a permanent handle which is created and stored in a door object as part of the BIM information. The Placement Tool would request the user to select the desired tag from a tag list which the tool has created by searching the symbol library for symbols containing the pre-defined field name. The user would then attempt to select the object (a door) to link their tag to and then click where they want the tag placed. Any number of tags can be placed where ever the user desires and they link to the unique door instance. Update that instance and all tags linked to it have the ability to refresh their information. An alternate function of the Placement Tool could be to select the object (a door/a window/a cabinet) and the Placement Tool would then place the selected tag at every instance of the object which appears upon the layer which the selected object resides at the origin of each instance object. The challenge I see is ensuring that whenever a door object gets created, duplicated or pasted that it checks for the preexistence of its serial number and changes itself to be unique. And whenever a referenced object is deleted that the tag(s) linked to it realize their source is missing and delete themselves too.

Actually I guess it would be the plugin instance which generates the symbol and loads it with data from the object that would have to store the serial number of said object; not the symbol object's record because the symbol gets reinserted and regenerated with each refresh of the plugin. The Placement Tool would set the initial serial number data into record of the instance of the tag controlling plugin.

 

This is similar to a titleblock plugin I created that utilizes a page based symbol for layout and a special instance of itself for maintaining the same project name, client name, and project number through out a file. The plugin looks through all instances of itself for the flag that identifies the special primary instance to copy data from. If it doesn't find one it checks what sheet of layer it has been placed upon and compares it to a string contained in its script's definition. If the string matches the sheet name it changes its own flag to identify itself as the primary titleblock and makes those three fields visible for editing in the info palette. It works pretty slick because if you copy another primary titleblock into a file with an existing primary the regen process allows the script to turn off the flag of the instance being copied in and if the copied instance doesn't find an existing primary it is going to check if conditions are right to make itself the primary which retains the data brought over from the other file.

 

But first Nemetschek is going to have to fix the scaling bug associated with page based symbols that are outside of the viewport being edited. When there is an instance of a plugin which is placing a page based symbol on a sheet and you are in annotation edit mode of a viewport also on that same sheet that symbol instance gets rescaled to the viewport's scale instead of maintaining the scale of the environment in which it is placed. It would drive one bonkers if there were more than one or two instances of the plugin on the sheet with all those useless snap points of the symbol instance potentially behind the view port you are attempting to add annotation to.