A detail component database contains a size table for each available component and several related tables that support the overall structure of the Microsoft® Access database. A component database has references to external files, such as Recipe Specifications and preview image files. For this reason, it is suggested that the database and all of its external references be located in the same tree structure of the file system. For example:
MyContent/MyComponentDb.mdb MajorComponentGroup1/*.xml, *.dwg, *.png, etc. supporting this group of componentsMajorComponentGroup2/*.xml, *.dwg, *.png, etc. supporting this group of components
Such a structure makes installing or moving the content a much easier task because all of the external content can use relative paths from the main database.
Several tables must be present in order for the Recipe system to function correctly. When creating a new database, you should start with either the standard database (AecDtlComponents.mdb) or with the empty template database (AecDtlComponents-Template.mdb).
This table uniquely identifies a component (or keynote) database with a Global Unique IDentifier (GUID). It also provides information that can be displayed in the user interface. All detail components placed in a drawing, and all detail component tools used in Tool palettes record this database GUID. If your database changes location in the directory structure, the tools and components can still find the database using the unique GUID.
The Type field should contain either the string “Component” or “Keynote” depending on which type of database you are creating.
To obtain a GUID for your database, simply delete the existing GUID from the database you are using as a template, and a new GUID will be generated automatically.
The Groups table defines the hierarchical organization of components within the database. This hierarchy determines the order in which component groups are displayed in the tree view of the Detail Component Manager dialog box. To set up this table, you simply need to make a Group entry for each collection of like components, and then, for each Group, define its Parent, which is either another Group or the root node (\ - *). The following fields apply to each row in the table:
A unique number within the given table that identifies the particular row in the table used to create a component. Once created, this number should never change. Components that have already been placed in the drawing are stamped with this ID and must be able to consistently reference this row in the database.
The group that is the parent of the group identified in the Group field.
The text string used to display the name of this group.
An entry from the DirKeys table (described later in this section). DirKeys tell the system where to find the files external to the database for this given component.
A comma-delimited list of keywords used by the Detail Component Manager to search for components. When a keyword is specified for a group, any component within that group is considered a match for a search on that keyword.
A Boolean flag indicating whether this row has been changed since it was originally created. If the user modifies the row using the Detail Component Manager dialog box, this field is marked so that future versions of the database can merge in the changes. The notion of “modified” is relative to the version of the database. For instance, if you are copying an existing database and changing all the values, it would be considered the first version of the new database, and all MODIFIED fields should be set to FALSE.
This column allows you to specify a unique picture when this Group node is selected in the Detail Component Manager. It is recommended that you use an image file of type PNG. The location of the image file is usually specified by appending the filename to the path assigned to the DirKey for this Group.
The Components table is the main “map” of how all the information about a given component is tied together. The following fields apply to each row in the table:
A unique number within this table that identifies the particular component within this database. Once created, this number should never change. Components that have already been placed in the drawing are stamped with this ID and must be able to consistently reference this row in the database.
The parent Group of this component. This establishes the place of the component in the overall hierarchy of components.
The text string used for display purposes in the Detail Component Manager and on the Properties palette.
The name of the size table for this component (Component Size Tables are described in the following section).
This value references an entry in a keynotes database. This is the default keynote to be used for all sizes of this component, but it can be overridden if a size-specific keynote is defined in the size table.
This value identifies the component as a valid subcomponent for the context specified. For example, the Recipes for Brick and CMU allow for a subcomponent of mortar. The Recipe system will search for all components in the database that identify themselves as being valid subcomponents for mortar.
This value specifies the XML file to use as the RecipeSpec for this component. The RecipeSpec has instructions for how to actually create and place the component in the drawing. The RecipeSpec is found by searching in the directory specified by the PathKey for the Group in which this component resides. For more information, see the subsequent section on Recipe Specifications.
A comma-delimited list of keywords used by the Detail Component Manager to search for components.
This value specifies the unit of measure for the size table for this component.
A Boolean flag indicating whether this row has been changed since it was originally created. If the user modifies the row using the Detail Component Manager, this field is marked so that future versions of the database can merge in the changes. The notion of “modified” is relative to the version of the database. For instance, if you are copying an existing database and changing all the values, it would be considered the first version of the new database, and all MODIFIED fields should be set to FALSE.
This column allows you to specify a unique picture to display when this particular row is selected in the Detail Component Manager. If the field is left blank, then the picture specified at the Component level is used. If no picture is specified in the Components table, the picture specified for the component’s Group is used.
It is recommended that you use an image file of type PNG.
For each component in the database, there should be a corresponding size table. A size table can be named anything you desire, but must include the following columns:
A textual description of the item, which is used as a display string in the Properties palette.
A unique number within the given table that identifies the particular row in the table used to create a component. Once created, this number should never change. Components that have already been placed in the drawing are stamped with this ID and must be able to consistently reference this row in the database.
A Boolean flag indicating whether this row has been changed since it was originally created. If the user modifies the row using the Detail Component Manager, this field is marked so that future versions of the database can merge in the changes. The notion of “modified” is relative to the version of the database. For instance, if you are copying an existing database and changing all the values, it would be considered the first version of the new database, and all MODIFIED fields should be set to FALSE.
This column allows you to specify a unique picture to display when this particular row is selected in the Detail Component Manager. If the field is left blank, then the picture specified at the Component level is used. If no picture is specified in the row of a given size table, the picture specified for the Component in general is used.
It recommended that you use an image file of type PNG.
The location of the image file is usually specified by appending the filename to the path assigned to the DirKey for this component’s Group.
If the component is created by doing a simple Block insertion, you can have the preview image created dynamically by drawing the referenced block. For these types of components, set the Picture value to _blockthumbnail.
This value references an entry in a Keynotes database. As with the PICTURE column, if no value is specified here at the Size level, the one specified at the Component level is used.
This table defines the units of measure available to assign to individual component size tables. It currently includes only inches and millimeters. However, centimeters, meters, and feet should also work. In the Components table, each entry must specify the unit in which the assigned size table is defined.
This table defines directory keys, which are shortcut aliases to use in identifying the directory structure of the user’s file system. Typically, there is one directory for each major division in your component hierarchy. You can match the component hierarchy in the database with the external files stored on the file system.
DirKeys are referenced in the PathKey field of the Groups table and from the XML RecipeSpec files. They are intended to allow you to easily reorganize the internal hierarchy, the external hierarchy, or both.
Column names used in component size tables cannot be localized in other languages because these names are referenced programmatically. However, these column names also need to appear in the user interface. The ColumnDisplay table serves as a lookup for user interface components, so that user-friendly, localized names for the columns can be displayed.
This is the fixed name of the column in a given component size table. It is the lookup key used to find the local name.
This is the translated, user-friendly display string to use for a column of this global name.
If left blank, then any column with the given GlobalName uses the LocalName for display purposes. In some cases, however, the same column name may have two different translations depending on its context. Specify a size table if the translation only applies to a specific context.
Some columns, such as ID and MODIFIED, are not intended to be seen by the user in the Detail Component Manager. These can be hidden by checking this box. Note, however, that this only applies when the database is marked as read-only. A database that is being edited from the Detail Component Manager must show all columns so that a valid row can be entered.
A Boolean flag indicating whether this row has been changed since it was originally created.
This table defines a set of hatch aliases. Individual components that create hatches can reference an alias instead of specifying the pattern, scale, and angle directly. This allows you to standardize the look of certain materials across the entire database. For instance, you can have all components that are made of concrete use the “concrete” alias. If you want to change the look of all concrete components, simply edit the entry in the Hatches table to change the look of any component that references that alias.