Autodesk 00128-051462-9310 User Guide - Page 2186

Step 3: The RecipeSpec may have one or more Recipes defined within it, each associated with a different View setting on the Properties palette. By selecting a View (or accepting the default) the user in effect selects the Recipe that is responsible for creating that view of the component. When a particular Recipe is selected, the Recipe Implementation function described in the XML RecipeSpec is called. The three controls shown under Specifications (Hatch block, Grout fill cores, and Show mortar) are defined by the section of the RecipeSpec. Their values can be retrieved by the Recipe function and used to control the basic parameters of the component. In this example, Mortar is a subcomponent of the CMU component, as specified in its RecipeSpec. Values and options for all mortar components are retrieved from the database and displayed on this section of the Properties palette. The final three controls under Mortar (Left joint type, Right joint type, and Hatch mortar), are specified in the subcomponent's RecipeSpec, and their values can be retrieved by the subcomponent's Recipe function. Step 4: The Recipe Implementation then does whatever it needs to in order to create the component. It has access to the size data in the database, the data in the RecipeSpec, and user input provided through the Properties palette. It also has access to a host of utility functions that can help create and place the component. The layering and hatch properties for the component come from the section of the ReceipeSpec. Specific options for the Jig to use come from the section of the RecipeSpec. Component Databases 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 components MajorComponentGroup2/ *.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. Database Schema 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). Fingerprint Table 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. Groups Table 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: 2146 | Chapter 52 Customizing and Adding New Content for Detail Components