DESIGN TOOL AND METHOD FOR PREPARING PARAMETRIC ASSEMBLIE

I. Field of the Invention

This invention relates to a design tool and process for selecting and organizing interconnectable components and for designing, describing, displaying and manufacturing products having a number of variable characteristics. In particular, this invention is useful for specifying and designing assemblies of modular furniture components and perfiision kits and for manufacturing wire harness assemblies, propellers, bolts and other fasteners.

π. Background of the Invention

Many industries are faced with the problem of assembling diverse components into final products which generally are different for each customer or application. For example, in the office furniture business, several manufacturers, including Herman Miller, Steelcase and Westinghouse, offer lines of components which can be interconnected to assemble modules with partitions, writing surfaces, storage, lights, etc., in a nearly infinite variety of different configurations. In some office environments, different modules are assembled to provide work rooms, secretarial stations and offices for all levels of employees.

Another industry facing similar problems is the manufacture of perfiision kits. A perfiision kit is used by doctors during surgery to handle blood outside of

the patient's body. A perfiision kit may include an assembly of any of a number tubes, branch points, valves, needles, injection ports and monitoring options.

A persistent problem in designing and assembling collections of diverse components is the need to keep track of a large number of small components. Fo example, a typical modular secretarial station might consist of several wall units, multiple filing units, a typewriter surface, a desk, power inputs, lighting, plus numerous fasteners and plates which vary depending whether the module is free standing, adjacent to another module, or between two or more other modules. If facility has 25 secretarial stations which are essentially identical but have some variations, the number of individual components can be very large. In order to keep track of all of these parts, the industry has developed specifiers or computer programs that facilitate counting how many of each type of component are needed. Some manufacturers distribute current pricing and other information periodically in a computer readable format, which can be read into a specifier to generate a purchase order.

The designer must order enough parts to assemble the modules, the manufacturer or distributor must ship enough parts and the assembly crew must be able to locate the parts to assemble each module. In practice, even with the assistance of a specifier it is difficult to keep track of the large number of discrete parts and industry practice is to order excess basic components, such as fasteners, to be sure enough are on hand to do the final assembly. This is wasteful of resources and adds to the cost of each assembly.

Others have used expert systems for layout and design (see Watanabe et al., U.S. Patent Nos. 4,651,284 and 4,700,317; Hartsog, U.S. Patent No. 4,964,060) or have sought to develop improved modelling or space planning methods (see Thomson, U.S. Patent No. 4,642,780; Aish, U.S. Patent No. 4,275,449). None of these references teach the present device or method or hav been able to produce or manipulate the sophisticated and easily editable assemblie of the present device and method.

TTT. Summary of the Invention

The present system and method provides a design tool for designing an assembly which is a combination of components, each of which can be described by a selected number of variables and which may be available or may be made in different forms. The design tool includes a rule base, a knowledge base and an inference engine. The knowledge base includes a plurality of records pertaining t types of connectable components, where there is a record containing characteristi for a connectable component and rules as needed to define combining the component with other connectable components. The inference engine includes means for selecting a record for a first component, means for selecting a record f another component to be connected to the first component, and means for storing information about a plurality of connected components to form an assembly.

The design tool makes use of constant and variable characteristics to defi and manipulate components and assemblies. Constant characteristics include component name, component description, manufacturer identification number, pri

information, availability information, dimensions, color or texture. Variable characteristics of an assembly may include information about whether more than one component has been selected and, if so, information about a second component and how and where the second component is connected to a first component.

One object of the present invention is to provide a convenient system and method for selecting interconnectable components and designing assemblies of the components where only allowed connections can be selected and a corresponding physical assembly can actually be constructed.

Another object of this invention is to provide a system for inventory and ordering control.

IV. Brief Description of the Drawings

Figures IA, IB, 1C and ID, respectively, illustrate four different views of an assembly with three frames, a work cabinet on one side and a workstation, with desk, light, shelf and drawers on the other side.

Figure 2 illustrates a product list for the assembly in Figure 1.

Figure 3 illustrates a screen display with menu choices which can be selected for the displayed Active Component in an assembly.

Figure 4 illustrates another screen display with menu choices which can selected for the displayed Active Component in an assembly.

Figures 5A and 5B illustrate a logic flow for menu traversal.

Figure 6 illustrates a flowchart for the first method of deleting a component.

Figure 7 illustrates a screen displayed after DRC, showing items which failed a completeness check.

Figures 8A and 8B illustrates two flowcharts for adding a component to the design database.

Figures 9-29 illustrate screen plays for a design process.

V. Detailed Description

A. Overview

The present invention may be utilized with a variety of different systems. A system is a functionally related group of elements or components or an object describable by a bounded group of parameters. The present invention is capable organizing and interrelating components of a system according to the characteristi of the components and predetermined rules. The components of a system are use

by the design tool of the present invention to form a design. This design is described by a design database.

The basic criteria which make a particular system well suited to representation by a design database, and therefore, well-suited to application of the present invention, are: 1) the components of the system can be combined in many different ways; and 2) a limited amount of information can describe a combination of the components of the system.

For example, systems which are well suited to the design tool include but are not limited to:

a. Systems Furniture. This is furniture which exists in large numbers of components which are assembled according to customers' designs. A system may consist of several hundred to several thousand different components which fit with other components of the system. Several manufacturers manufacture one or more systems some of which include components which may be used interchangeably between systems.

b. Perfiision Kits. These are assemblies of standard and variable components made and assembled on a custom basis according to physicians' designs. They may be used to handle extracorporeal blood during surgery.

c. Other Assemblies: wire harness assemblies; HVAC; plumbing; telephone cable routing; motors.

d. Impellers and Propellers. These generally are single component designs which are generated from a system whose elements are materials and geometric constraints.

e. Other Single Component Designs: fasteners; bolts.

For purposes of illustration, this document will deal with the systems furniture application of the design tool. Compass directions assume north is up, east is right, etc.

The following description is set forth in sections. The first section contains definitions of terms frequently used in connection with the description of the invention. The second section deals with the structure of the design tool as a framework for use in different applications with reference to the currently preferr embodiment of the furniture systems. The third section discusses customization o the design tool for specific applications, e.g., for a specific manufacturer's line o systems furniture. This process is typically implemented under the direction of a programmer and an experienced designer. The fourth section describes the syste specific features of the present invention in greater detail and the last section deal with examples operation of the present preferred embodiment. This process is typically carried out by everyday users, who need have little experience yet can design functional assemblies.

B. Definitions

A number of basic definitions are set out in this section which may assist the understanding and explanation of the present invention. The following explanatory discussion is not meant as a complete glossary, since many terms are introduced elsewhere, in the logical flow of the description.

In a systems furniture application of the present invention, the system is a collection of different furniture items, such as wall-units, shelves, connectors for same, etc. These furniture items are components within the system made by a manufacturer. Components are designed to fit together interchangeably, for example, a shelf may be available in a predetermined number of widths (e.g. 24", 36" and 48") which are the only widths available for shelf supports (frame, tile, etc.).

One of the basic components of a furniture system is a frame, a generally rectangular structural component. A frame can support various components such a storage cabinets or work surfaces. Referring to Figure 1, a number of components are illustrated. Frame 10 is attached to empty frame 11 and wall cabinet 12.

Frame 10 has been completed by adding attachable components storage cabinet 13, light 14, work surface 15, pencil drawer 16, and suspended drawers 21. The remaining open spaces on each side of frame 10 are filled, in this example, with a full set of tile faces, four acoustic tile faces 17 and four mahogany wood tile faces 18. Figures IA, IB, 1C and ID represent views of the same assembly.

A component can be described in terms of its attributes, preferably define by one or more constant characteristics generally sufficient to describe the component. A constant characteristic is constant for a specific component but variable between components and might include color, height, width, depth, texture, powered, non-powered, and other characteristics needed to describe the component and distinguish it from other components in the furniture system. Oth useful constant characteristics may be associated with a component such as a description of the component suitable for use with a CAD display program (e.g., library file for AutoCAD ^® ). Still other useful constant characteristics may define points on the component at which other components can be connected. The constant characteristics of individual components may be stored as variables in one or more constant databases such as the part database, geometry database and optio database described below in Example 1.

Some components are primitive components which are unitary component not divisible into other components. Some components are custom components which may be defined and recorded in a design database or incorporated into records similar to the records for individual components. Once defined, these custom components function just like other individual components or primitive components.

An assembly is a collection of one or more linked components. The design tool allows linking components in essentially any configuration which is possible with the actual, physical components. Each assembly is represented by a

design database which will be described in detail below. An assembly may includ not only individual components but also other assemblies, sometimes referred to as "sub-assemblies" or included assemblies.

The design database contains individual records for each component of the assembly. Each record references information which describes the component, e.g., a record in the part database for that component. A design database for an assembly can include entries for essentially any combination of components and assemblies. A design database entry for a component references pertinent information about that component in one or more constant databases. A design database entry for an included assembly references another design database, one for the included assembly.

In one application of the design tool, the final product is a single component but the design tool is used to select materials and geometric features, e.g., the pitch of threads on a bolt. In such a system, an assembly is a collection of parameters or other constant characteristics. Other examples of a single component system are manufacturing of impellers and propellers which have variable structural characteristics and materials as system components.

The design tool can accommodate certain special assemblies such as a "Tile Typical" or an "Interior Typical. " These special assemblies consist of a group of components fixed in space relative to each other but without a specific position or orientation in absolute space. In general, these components do not need to be, and are not, connected to each other. These special assemblies can be

connected during the design process to another component or assembly to comple certain design needs.

A Tile Typical is a characteristic choice and arrangement of tiles for use on the surface of a frame. One or more tile Typicals can be preselected to accommodate the design goals for a project. Referring to Figures IB and ID, til descriptor 17 refers to a Tile Typical consisting of four acoustic tiles, 48 inches wide. Information on the specific part numbers, dimensions, etc. is available. In figure ID, the tiles are shown in a three-dimensional projection, largely hidden b the tiles of Tile Typical 18. Tile Typical 18 consists of four wood tiles, also 48 inches wide. Tile Typical 17 has been selected for the "north" side of frame 10 and Tile Typical 18 has been selected for the "south" side of frame 10. A menu selection of pre-defined Tile Typicals is illustrated in Figure 24.

An Interior Typical is a special assembly of interior components. An

Interior Typical might consist of a series of work surfaces, drawers, cabinets, etc. for use in a typical work area for an employee cubicle. Another Interior Typical might be the interior for an executive module with a high grade of finishes, certai storage or light facilities, or other components selected by the system designer.

Since assemblies can be used in other assemblies, each time an assembly changed, that change can be marked, e.g., with a flag, so the design tool knows t check all marked included assemblies to determine the impact of any changes. If change in an included assembly renders the existence of the including assembly logically impossible, the included assembly is deleted from the design database fo

the including assembly. For example, a change to an included assembly may resu in that assembly being too large for the available volume in the including assembl in which it is installed.

A cluster is another special assembly, one that is "complete" or one whic has no open connection point which must be connected to another assembly or individual component. For example, a component such as a frame should be filled on essentially all faces and edges, by, for example, a complete set of tiles or other components plus a top cap and either a connector to one or more other frames) or an edge cap. It may be possible to add additional components, e.g. one or more shelves to a frame in a cluster, but no component in a cluster needs to be connected to any additional component to be complete.

One or more clusters can be placed in space to complete a design. For example, a complete design may have one cluster designed as a secretarial work group, another cluster designed as an engineer work group, and a third cluster designed as an executive work group. A complete design might consist of a certai number of secretarial clusters, a number of engineering clusters and a number of executive clusters. The complete design could be the sum collection of each of these clusters.

Another feature of the design tool is a "space plan." In a preferred implementation, the space plan begins with an outline of the available space, for example, a blueprint of the building shell. Clusters or other assemblies can be placed within the building shell in a non-contiguous manner. For example, one

suitable assembly can be a mere outline of a cluster without completing the entire cluster. A user may represent a large design schematically without finalizing details until overall design criteria have been satisfied.

Clusters can be placed within a "building shell" in a non-contiguous manner to form a "space plan," which encompasses the entire design. Building shells are volumes defined by the system. Accordingly, a design database for a space plan assembly may reference design databases for one or more cluster assemblies or free standing components used in the space plan. Cluster assembli may reference one or more Tile Typical or Interior Typical assemblies.

Throughout this description where the use of an individual component is contemplated, a primitive component, custom component, or assembly may be us interchangeably depending on the physical constraints of the system.

The design tool for a given system is fully determined, which is to say that preferably all legal assemblies can be designed and no illegal assemblies can designed. In actual practice, it is sufficient to design most legal assemblies and almost no illegal assemblies.

A design is all the furniture in one project and how it is combined. A project is the user's requirement of systems furniture for a specific application. For example, a customer may commission a vendor to complete a project which consists of furnishing an office. As a part of this project, the vendor will use the design tool to arrive at a furniture design.

The concept of variables as used in the present invention is important to the design process. For example, variables define the status of an assembly durin the design process. The status of a component is the combination of constant and variable characteristics which are relevant to the design tool at the time the design tool is performing an operation which modifies or checks the current configuratio of a component. For a preferred embodiment of the systems furniture application, the software maintains the values of some three hundred different variables in the form of unsigned short integers. These variables govern the actions of the design tool. A selected subset of these variables is saved with each record in the design database and describes the variable characteristics of the logical condition of the component which corresponds to that record. The number of variables required depends to a large extent on how many types of components are available from th manufacturer, how they fit together, which combinations are and are not allowed, etc.

C. Structure of the Design Tool

As described below, the design tool consists of several parts, including a knowledge base, a rule base, an inference engine, an expert user interface and a graphic system. These parts of the design tool are integrated with information regarding the specific characteristics of the components of the furniture system and how they interrelate so that the design tool will be capable of creating a design for the particular furniture system.

Other parts of the design tool which will be discussed in this section include the documentation control and automated output control. This section will describe the general structure and functional interrelationship of the parts of the design tool.

1. Knowledge Base.

The knowledge base is a set of databases containing information pertainin to components within the system which are the subject of the design tool application. Generally, this information consists of the constant characteristics for each component. As discussed above, constant characteristics for a component which may be stored in the knowledge base include connection vectors, graphical information such as drawings of the component, assembly instructions and availability. Connection vectors are represented by vector variables which correspond to potential connection points for a component and whose correspondi values as stores in design databases describe the current geometry of the connections for that component.

The knowledge base is a basic component of the design tool, although th specific databases required to describe and manipulate a given system may vary with the application. The following discussion and examples describe a series of databases useful for the preferred implementation of the design tool for the system furniture. One skilled in the art can select and create appropriate databases for a variety of applications that come within the teachings and claims of this invention.

The information to be entered in the knowledge base depends on the particular system modelled in the design tool. This information might come from manufacturer's catalog or from other sources. In general, this information should be entered and checked carefully. This entry typically is done by or under the supervision of an experienced programmer.

2. Rule Base.

The rule base contains rules for what components can be combined with other components and under what conditions they can be combined plus what components must be present under certain conditions. Rules are used in the design process to allow proper combinations of components and disallow improper combinations. These rules are preferably based on characteristics of each component which depend, in turn, on the system in use, e.g., a certain frame or type of frame can be connected to a certain type of connector or a certain type of tile. The rules should accommodate different states of a component, for example, combination of the first component with a second component may be allowed for the first component alone but a subsequent combination with a third component may be affected by the fact and nature of the combination of the second componen with the first.

In the preferred embodiment of the present invention the rule base consist of two parts: (1) a menu database which includes rules for menu selections and (2 global rules. The menu database contains rules which define whether and how a component can be connected to another component. The rules included tests for

various conditions, e.g., the presence or availability of certain types of connectio or components. The rules also control the display of menu options, preferably showing only options which are possible at a given stage of the design process an not showing or otherwise indicating choices which are not possible at that stage. Preferably, the present invention is menu driven. That is, during the design process the user makes selections from a list of displayed selections. These rules operate to constrain the design process by limiting the selections available depending upon the component upon which another component is to be added.

Some rules govern the selection of defaults by a user. Before beginning the design process the user may select certain options which will either limit subsequent menu selections or cause selections to be made automatically.

Global rules govern the interaction of components which are not necessarily directly linked to one another. Global rules might not be useable during the design process to determine what components may be combined with other components and how the components can be combined. That is, the combinability or state of a component may change dependent upon the addition o other components in such a way that the change cannot be detected during menu traversal. During menu traversal the rules are dependent upon the known information for a component to which another component is being connected. Thus, there is limited access to or use of information during menu traversal durin the design process regarding other components which may impact the combinatio of two directly linked components.

3. Inference Engine.

The inference engine selects and applies rules from the rule base using information from the knowledge base to direct and implement the design process. The inference engine passes information from the design database to the graphic system, described below, to display selected information from the knowledge base according to the rules in the rule base. During the design process the inference engine accepts input including user choices through menu selection and input based on application of rules.

The inference engine calls the design rule check (DRC) when a design is saved. The design rule check applies the global rules to the complete design database to detect errors in design. In the preferred embodiment, the design rule check checks local design rules which are for the most part taken care of by the design process. The global design rules test for design completeness and for proper interaction of components and not just the characteristics of individual components. Example 6 below further describes the design rule check in connection with its operation.

4. Expert User Interface.

The expert user interface includes a series of menus, presented to the user by the inference engine in accordance with the rules and conditions in effect at the time. The expert user interface is applicable to many parts of the design tool and minimizes the program user's steps required to control the design process.

The expert user interface is responsive to user commands to control program operation and cause the creation of a design. The expert user interface directs the creation of the design by means which will be described more fully below through examples but which employ the knowledge base, rule base and inference engine.

The user may select a component by a user mouse digitization (mouse button press at a screen location) which makes the selected component active. T design tool permits components to be randomly accessed or selected from within the design when selecting a component.

The expert user interface minimizes the required input into the design process by the user by only allowing the user to select viable menu selections during the design process and by outputting meaningful messages as a result of th design rule check. Additionally, the expert user interface will make selections fo the user whenever possible. For example, if certain default conditions have been established (typically stored in a default database) then whenever the interface can make a decision based on default information, it will do so. If a user preselects default that all new frames will be powered and have a certain height, then whenever the user would have been presented with the option of selecting powere or not, the interface will automatically make the selection of powered. Similarly, when the user would have been presented with the option of selecting frame heig the interface will assign the frame height based on the default values. These

defaults can be applied to many types of components without preconfiguring each component type.

As another example, if the height of an attached component is required to be a certain value in order to be attached, the expert user interface will make the height selection without consulting the user. As another example, if a group of frames has the correct configuration to connect to the components of an Interior Typical, the expert user interface and the inference engine will effectively make al required connections automatically.

5. Graphic System.

The graphic system produces graphic representations of the design or portions of the design during the operation of the design tool. The graphic system can display images of components, assemblies and designs by referring to the design database and knowledge base. The graphic representations of the current design are updated and displayed as the design is changed.

The graphic system includes tools which allow the user to make basic display modifications such as zooms, pans, windowing, and graphic displays of different information about the design. Graphics are produced automatically based on information in the databases; the user never manipulates the graphics directly but the graphics visually "echo" the design database. Metagraphics version 3.8A( now version 3.7C used) was used to provide the graphics environment (primitive graphics functions) under DOS.

The graphic system also can display part numbers, e.g., 20 in Figure IA or information about components or surfaces. Figures IB, 4 and 7 include readouts for Tile Typicals 17 (four acoustical tiles, in order, top to bottom along the frame) and 18 (four wood tiles).

6. Documentation Control.

These tools control the automatic filing and revision assignment of the design database for a design of the project. Filing and revision information is stored in the Project Database and in an assembly level database, i.e., the CIT database.

7. Automated Output Tools.

At various points in the design process, or external to the design process, the user may elect to automatically produce various forms of output. The design tool refers to the design database and knowledge base, which together completely define a design, to automatically create reports or representations of the design in other usable forms such as:

a. Bills of materials. b. Inventory modification and order entry information. c. Manufacturing and QA instructions. d. Just-In-Time manufacturing process.

e. Plots, e.g. on paper media. f. Quotations. g. Assembly/Inspections times. h. Shipping information (volume, weight, delivery schedule). i. Manufacturing Resource Planning (M.R.P.)

Design information can be accessed in a usable form to create representations of the design in many other forms. These forms include the output listed above, as well as representations of the constraints under which the design was created (this could include, for example, a listing of the user selectable rules in place during design). The design database, or a set of design databases, can also be referenced for statistical analyses of their components.

One of the automated output tools interfaces with computer aided design software to produce two or three-dimensional representations according to a CAD image database. These CAD models can be wire-framed, surfaced or solid modeled. See Figures 1A-1D. Tool paths and/or post processed numerical control (NC) files used for the automated machining of parts may be produced from the CAD models automatically.

External to the design process, or within the process by way of constraining the possible generation or insertion of sub-assemblies, the design tool is ideally suited to the incorporation of group technology. Group technology can be used to assign certain values to database entries which are dependent on or reflect selected parameters within the database entry. That value can be used to

quickly search for database entries that have selected parameters. In addition, group technology can be used to examine the design databases.

One useful platform for implementing this invention is an Intel-386-base computer running under MS-DOS 3.2 or higher. A color VGA monitor is useful although an EGA monitor can be used. A hard disk is recommended, e.g. 40 MByte. Some implementations of a program using this invention may require m than 640K base RAM. Phar Lap Software 386 {DOS Extender can be used to avoid this limitation. The protected mode version of Metagraphics (Metagraphics Premium, Version 3.8A), version 6.0 of c-tree File Handler, and the Watcom C

8.0/386 compiler were used. One skilled in the art will recognize other platform compilers and software accessories that can be used successfully to implement the present invention.

Currently, .RTLinkPlus made by Pocket Soft is used instead of the Phar

Lap DOS Extender. Further, the real mode of the Metagraghics graphics softwar is used, as well as, version 4.3 of the c-tree File Handler, and a Microsoft C compiler.

D. Customizing the Design Tool to Specific Applications

The design tool must be customized to operate with specific systems. Information specific to each system must be input into the various parts of the design tool for that particular system application. The type of information which must be integrated into the design tool includes design constraints and component

information. As discussed above there are many systems to which the present invention may be applied. In a present preferred embodiment the design tool is applied to furniture systems.

Design constraints are generally those rules which govern the formation o designs. As discussed above in the definition section, rules are stored in the rule base. In the furniture systems application an exemplary type of rule governs connection of components or classes of components which have corresponding connection points which match in height and type of connector so adjacent components may be physically connected.

Some overlap exists between design constraints or rules and component characteristics in that the rules for a particular system are heavily dependent on component characteristics. Many rules relating to the compatibility of components to be linked refer to the dimensions of the respective component and, therefore, are a source of component characteristics.

Design constraints and component characteristics are generally entered by a programmer or designer of the particular application for the design tool since this information defines the design process and effectiveness of the expert user interface in facilitating the use of the system by individuals who are not designers for the particular system. Entry of the design constraints includes determining appropriate operational choices to be displayed in the menus of the design tool. Further the storage of the component information must be structured effectively to enhance the overall operation of the design tool.

Customization of the design tool to a particular system also involves structuring the graphic system and automated output tools. The graphic system is designed to enhance the visualization of the ongoing design process. The automated output tools are designed to produce outputs which are useful to the user.

E. Using the Design Tool

Using the design tool to produce a design database is an interactive proce wherein the user is allowed to make legal designs, that is, physically constructable designs, and prevented from making illegal designs, all without requiring any specific technical knowledge of the software and generally without extensive knowledge of the components available in the system. This interactive process is menu driven and mouse controlled, with a menu on the left side of the screen and graphic window on the right side.

The design process is menu driven in the sense that the expert user interface operates to furnish a number of possible operational choices in a menu which the user selects from. The menu lists available legal operations which may currently be performed on the design including components which may legally be added. The graphic window shows a graphic representation of the design in its current state. The user may use the mouse to make a menu selection or to select component of the design represented in the graphic window. This process of

mouse selection is often referred to as digitizing (or "diging") a menu selection or component.

Example 8 below illustrates the operation of the design tool in forming an assembly. The process of Example 8 is illustrated in connection with Figures 3, 4, and 9-29 which are screen dumps taken from the display screen during the design process. This example illustrates the physical operations that a user performs in implementing the processes described throughout the current application.

1. Summary of Operation

a. Set Default Values

In a presently preferred embodiment of the invention, the user may set certain defaults, if desired, which will govern the general characteristics of the design, e.g., selection of materials or the height of a structural component such as a frame. For each variable which is not set to a default value, the user will have to enter the appropriate information for each component affected by that variable. Thus, use of defaults facilitates both consistent and rapid design of an assembly. The default information is stored in a default database.

Information in default databases allows automatic selection on some menus during the design process. They also set some basic conditions of the design environment. This information in the default databases can be modified by the user prior to or during the design process (through the user commands). In setting these

default conditions the user is placed in the same expert menu environment used t govern the creation of design databases, generally without a graphic area. For th furniture systems application, the setting of user defaults is sufficiently complex t warrant such control to prevent conflicting or incomplete default conditions. Me traversal while setting user defaults modifies the default databases rather than a design database.

b. The Design Process

Design begins by selecting and inserting a first component in the design.

After the user selects the class of component, e.g., a frame, the design tool provides a series of menus from which the user can specify characteristics, e.g., height and width, powered or not, and color, necessary to select a unique component. Some of these characteristics may have been predetermined and stor in the default database so that they are autoselected.

An activatable component may be selected from a menu or from the currently active design by using a mouse to position the screen cursor over the component and clicking ("digitizing" or "diging") the component. Selection of an activatable component makes it the Active Component. The Active Component is highlighted and an active menu is displayed listing all of the operations which ma be performed on or with the newly activated component.

Components are generally of two types: activatable or non-activatable. activatable component can be made the Active Component while a non-activatable

component can not. Typical non-activatable components are unique components which can be connected to only one other component and cannot be modified,e.g., frame caps, carpet grippers or socket cover plates. Typical activatable components can be connected to more than one other component and are modifiable, e.g., a frame which may connect to one or more other frames, to tiles, to top caps, to carpet grippers, to work surfaces, to cabinets, and to many other components.

The design tool provides for a hierarchy of components. In a preferred embodiment of the present invention, activatable components are generally classified in an hierarchy and non-activatable components are classified in a separate hierarchy. The hierarchy is a deletional hierarchy in the present invention. For example, when an activatable component is deleted all non-activatable components linked to that component are deleted because the non-activatable components are in a lower deletional hierarchy.

Where there are other types of components which share consistent design rules and relationship to other components, e.g., a deletional preference, these components may be grouped into a hierarchy of components. Thus, the hierarchical classification of activatable and non-activatable components is not meant to be restrictive.

When creating a new assembly, the first component is selected through initial menu traversal and placed in the assembly coordinate system by aligning the assembly coordinate axes with the component coordinate axes at both coordinate origins. See Examples 1 and 8, below. The design tool is used to design

assemblies into building shells. Building shells are defined volumes into which an assembly must fit. Each assembly is assigned its own coordinate system. The coordinate system of the graphic area of the screen corresponds to the coordinate system of the assembly currently being designed.

The active menu for essentially each activatable component has a selectio called "User Commands" which allows the user to access the user commands. In space plan assembly this process is different in that all clusters are inserted from the user commands menu, while digitizing a cluster on screen opens the design database corresponding to that cluster assembly for modification and makes a component in the digitized cluster the Active Component. See Example 5 and Figure 8 for a flow chart of the addition of a component to a design database.

Once the user selects a component or existing assembly to be added to th design, information about that component is entered in appropriate databases and the graphic display is updated to show the component. The menu is updated to show legal additions or changes to the component, plus some system options. The user continues by choosing and specifying additional components or assemblies, gradually building up an assembly.

Each component in an assembly of components is assigned a component number specific to that component with reference to that assembly. In a preferred embodiment, the lowest available component number is assigned in the order that the component is added to the assembly. Thus, the first component selected for a assembly is assigned a first, i.e., least component number, initially, and the secon

component is assigned that number plus one. Each succeeding component is assigned the lowest, next available component number.

In the systems furniture design tool, every component except one is linked to exactly one other component of lower component number; this component of lower number is called the destination component for the corresponding linked component. One component of the assembly, called a root component, will have no destination component to which it is linked.

A component may be a destination component for more than one component. In most cases the linkage of a component to its destination corresponds to a physical connection but in some cases the components may be linked and have a fixed spatial relationship relative to each other but not be physically connected. For example, two adjacent, connected frames have a physical connection but a chair and a desk may be linked together logically in an assembly without any physical connection.

The interconnection of components for an assembly is available from the design database records but is also available from indexed values. That is, there is a list of all the component numbers used in an assembly and the destination component corresponding to each component.

In order to illustrate a preferred implementation of the device and method of this invention, the specific example of systems furniture design is described here. Example 1, below, provides additional detail regarding the various databases

used by the design tool as a precursor to examining the design process itself. Examples 2 and 3 detail variables, menu structure and the process of menu traversal. Example 4 describes the process which occurs when a user digitizes a new Active Component from the graphic display.

While designing an assembly, the user can elect to modify an included assembly design databases "on the fly". The user may also elect to create an assembly and may pre-load pertinent conditions of the current assembly into this new assembly. This pre-loading of design constraints ensures that the new assembly will fit logically into the current assembly at the current Active

Component. Both of these processes allow the user to make design decisions abou an assembly while considering (or being limited by) its use in another assembly.

When designing an assembly the user works within the coordinates for tha assembly regardless of whether the assembly being worked on is part of another assembly. Thus, the user only sees the graphical interface for the assembly currently being designed whether or not it is being created or modified. As part o this display, preloaded pertinent conditions may appear as phantom frames.

The assembly of primitive components into contiguous assemblies is accomplished by fitting them together within the assembly coordinate system in accordance with a set of expert rules. The expert user interface in conjunction wit the rule base governs the design process. The records in the menu database are indexed by menu number, each corresponding to a different set of selections to be displayed in the menu area of the screen. In addition to this text, each menu

contains the expert information which governs its display, its basic reaction to a menu selection, and some basic environmental descriptions such as whether or not the user may currently digitize a new Active Component. The reactions to a selection include: loading the next menu; adding a new component or sub- assembly to the design database; and changing variable values. See also Examples

2 and 3, below.

The number of, and the logical and physical relationships among, the components in a Tile Typical are completely determined by the design tool. Menu traversal under these conditions can be thought of as a branching system of logical possibilities beginning at the first component and ending at the pre-determined point of the last component.

Referring to Figures IB and 1C, components 13, 14, 15, 16 and 21 were added in a single user action by selecting a predefined Interior Typical, 003A in the menu shown in Figure 26. The Interior Typicals are notable for the fact that insertion of components in these assemblies is subject to wide geometric variation which must be logically controlled. To enable this, whenever an Interior Typical is being designed, a PHframe database is created and modified (see Example 1).

Cluster assemblies differ from Interior and Tile Typicals in that they allow the insertion of assemblies. To facilitate this, a variable CIT (Cluster Interior Tile) database is used to record just the characteristics of each extant assembly which need to be examined in order to determine whether or not the insertion of any given assembly is legal at the current Active Component in a cluster. This

prevents the design tool from having to generate this information from each assembly design database every time any assembly is inserted.

At this point we are ready to describe more specific operations of the design process which the user controls via the design tool under the constraints of the design tool.

3. Component Operations

After component selection, if the selected component is activatable that component is the Active Component and the menu displayed is the active menu for that component. A number of variables are maintained by the design tool which describe various aspects of the assembly in which the deign tool user is currently working. These variables represent the status of the assembly. Some of these status variables are specific to the current Active Component and are stored with the record for that component in the design database for that component.

The design process can be broken down into three separate processes: adding components, deleting components, and changing components.

a. Adding Components.

The addition of a component to the Active Component is accomplished by selecting a component or type of component from the menu selection in the active menu for the Active Component. The design tool leads the user through a series of

menus until the selected component is completely defined both in relation to constant characteristics and in relation to the assembly in which it now occurs. This new component record is added to the design database and to any pertinent temporary databases, and the graphic system portrays it on screen.

During the process of traversing the menu for each menu selection selected ones of the status variables are altered. The inference engine responds to each menu selection by changing information which reflects the consequence of that selection to the current assembly. A subset of this information, i.e., selected variables, is stored in memory in a record corresponding to the component once the component is added.

The added component has the component which was the Active Component at the beginning of the addition process as its destination component. The added component is linked to the destination component and is a new element in the current assembly.

Components may be added in between other components in a process called midrun addition. This process is similar to the process of midrun deletion described below. When a component is added between two or more other components the connectivity and vector information for each of the affected components must be changed as well as shifting the location information within the assembly coordinate system to reflect the changed position of the various assembly parts.

If the new component is activatable, then the new component becomes the Active Component and the user is presented with the active menu for that component. Otherwise, the new menu is the active menu for the previous Active Component.

b. Deleting Components.

Deletion of components is accomplished through the user commands. Whether or not a component is deletable is determined by its logical status as defined by the deletability variable. As discussed above, the deletability variable starts at zero for a given component and is incremented by one every time an activatable component is linked to the given component or the given component is linked to another component. Thus, if the deletability variable is greater than one then that component is linked to at least two other components. A root component which does not a destination component will only be linked to other components which have the root component as a destination component.

Each record in the design database for an assembly includes the deletability variable and the component number of the corresponding component's destination component, except for the root component which has no destination component number but does have a deletability variable. The deletability variable and destination components for each component in the current assembly are saved in a temporary database called T_isam as discussed below in Example 1. Storage in the temporary database permits quick reference during the design process withou

having to determine this information from each individual record in the design database.

Deleting a component will also delete all components of lower hierarchical value which are attached to the component to be deleted. That is, when an activatable component is deleted all non-activatable components attached to it will automatically be deleted. This said, there are two distinct methods of component deletion within a design database which are selected depending on the value of the deletability variable for the component which is selected to be deleted.

Method One. (Deletability equal to 1)

This form of deletion occurs when a component is deleted which will affect the logical status of some of the remaining components but will not affect the geometrical connections among them. By status we mean status variables such as the deletability variable and vector variables saved in the component record. By definition then, a component deleted according to this method must have no component of equal deletional hierarchical value which lists the component to be deleted as its destination component (unless it is a root component, which does not have a destination component to which the root component is linked and has exactly one component linked to it). Deletion of a component by method one may change whether or not its destination component (or in the case of a root component, the component of equal hierarchical valued connected to it) will be subject to deletion by method one or method two. Referring to Figure 6, the record number of the

component to be deleted is retrieved, the Least Item variable is set, an Object Number ("ON") variable is set and the Active Component variable is reset.

Accordingly, this first method of deletion is the simplest method and is used for components which are on the end of or at the beginning of a sequence of addition in assembling an assembly. That is, method one may be used to delete al non-activatable components, activatable components which have no other components linked thereto, and a component in an assembly which has no destination component to which it is linked, i.e., a root component.

In the case of the root component, there can be only one component listin it as a destination component for it to be deletable by method one. Thus, this method is appropriate for deleting end activatable components and all non- activatable components. In this end run deletion, the consequence to the assembly by the deletion of an end run component includes change of variables, and in the case of an activable component, deletion of all non-activatable components connected to it.

Method Two. (Deletability greater than 1)

This form of deletion occurs when the component to be deleted has one o more components of equal hierarchical value linked to the component to be deleted (or two or more if the component is a root component), and these components, along with the destination component of the component to be deleted (if it is not a root component), can be connected to one another automatically in accordance wit

the expert logic of the system after the component is deleted. This type of deletion is termed mid-run deletion, since it occurs when two activatable components are linked to an activatable component to be deleted, such as in the case where two frames are linked on either side of a frame to be deleted.

In the preferred embodiment of the present invention, this functionality is limited to mid-run deletion of frames, spacers and midrun cabnets. For example, a frame component which has activatable components connected on either side of it can be deleted and the resulting two halves of the assembly be brought together. This process requires that a portion of the assembly separated by the deletion of the midrun component be moved in space to compensate for the component deletion and the appropriate change in the status variables for the component which listed the deleted component as a destination component and the destination component of the deleted component be made. The movement of one half of the assembly in space requires that the graphics displayed be changed as well as location designators. Status variables which may have to be changed are vector variables, and destination component numbers.

When the user elects to delete components by digitizing a window in the graphic area in which all of the elements in that window will be deleted rather than selecting an individual component, the design tool cycles through all of the components within that window repeatedly until no components can be deleted in the current cycle. Each cycle of deletion will change the "deletability" of the components remaining in the window until none are deletable.

c. Changing Components.

Changing components in a design database is accomplished through the user commands. Components may be changed globally by logical type, through a digitized window, or individually through component digitization. When a component or a set of components of the same logical type is changed, the design tool cycles through the same set of menus used to describe the component(s) initially, allowing the user to make different selections. Previous selections are highlighted. There are two distinct method of change which can be made:

Method One.

The first method of component change alters the variable characteristics o the component but not its logical type, i.e., location (vector variables). This is a straight forward process of altering the values of specific variables which were saved with the component record.

Method Two.

The second method of component change alters both the variable characteristics of the component and its logical type. Some components cannot be changed by this method at all, while other components may be changed by this method only if its destination component and the components connected to it conform to a set of logical conditions defined in the expert system.

Through the user commands, the user may elect at any time to save, save with a new name, end, or quit from the design. Quitting from the design does not retain any changes made to the design database. Ending from the design first calls the DRC, then saves the design database in its current form.

4. Assembly Operations.

When working in a cluster assembly, the user may elect to insert a tile typical or interior typical at some point. At this point, the user makes the selection for addition of an interior typical or tile typical and is presented with a list of options which include existing tile typicals or interior typicals which would fit with the indicated portion of the Active Component.

At any point in time once an assembly is inserted into another assembly, an included assembly may be digitized for modification of the included assembly during the design process for including assembly. After an assembly is digitized the graphic environment and context of the design tool is changed so the user is now operating within the coordinate system for the digitized assembly. Any changes made to an assembly, even when installed in another assembly, will affect all uses of the changed assembly, even if it is used in other assemblies as an included assembly.

An assembly used in another assembly may always be deleted by a process similar to method one for component deletion since there is no capability for it

linking two subassemblies together or linking a component to an included assembl within the included assembly. Within a design database an included assembly is referenced primarily by its location and there is no capability of linking a component onto the included assembly.

Examples Example 1 Databases

The design tool for systems furniture uses the following Constant Databases:

a. Part Database.

This database contains records which each correspond to different manufacturer's part number for a systems furniture component. These records contain information such as: part number; description; options available (such as trim and finish colors); graphic to draw on screen; parametric graphic values; graphic to use in commercial CAD systems; price; weight; volume; and active menu number (the number of the menu from the menu database which should be loaded if this part is digitized by the user and made active).

b. Geometry Database.

This database is referred to by the part database and contains representations of all the possible vectors on a graphic which might be used to

connect a given component to another component. By the point to point alignment of connection vectors on different components, an assembly of components is produced. Variable values may modify this point to point alignment axially in either the coordinate system of the component being inserted or the coordinate system of the current design database assembly. Included assemblies are incorporated into an assembly similarly, or by recording the position and orientation of insertion of the included assembly.

c. Option Database.

This database is referred to by the part database and contains information such as: option names and descriptions; option upcharge prices.

d. Menu Database.

This database, a part of the rule base, contains records indexed by menu number. Each menu produces a screen display and has imbedded in it the logic governing this display and the basic responses to make upon a selection from this display. See Example 3 for a more complete description.

The design tool application for systems furniture uses the following Variable Databases:

a. Project Database.

b. Cluster Interior Tile (CTT) Database.

This database is project specific and is used to obtain information about sub-assemblies in the project without having to open each of their design database and develop this crucial information individually. The records in this database are saved whenever a sub-assembly is saved and occur in the following forms:

1. CITbase. These records occur for each cluster, interior or tile assembly and record: assembly number, revision, name and description; DRC success; and the number of CITpoi and CITgraph records associate to an interior.

2. CITpoi. These records record the physical locations in an interior assembly which must match with certain types of physical locations in a cluster assembly in order for the interior to be inserted into that cluster.

3. CITgraph. These records record the graphics to be drawn with each interior when it is inserted into a cluster assembly: graphic number; parametric graphic values; location and orientation in the interior coordinate system.

4. CITtile. These records store information about a single tile used in a given project: graphic number; and options. Because of this, when tiles are inserted they will be assigned the correct tile subscript by searching th Crr database for a CITtile record with matching characteristics.

5. CrrtileA. These records store information about a tile assembly which is used to determine whether or not it can be inserted onto a given frame component in a cluster assembly: width; height; logical types of tiles.

c. Design Database.

This type of database is the primary variable database which occurs for each assembly (or custom component) and records the complete variable characteristics of that assembly. Records occur for each component in the assembly and have slightly different structures according to the type of assembly represented (tile, interior, cluster or space plan). Each of these structures contains the complete logical description of the variable characteristics of the represented component in relation to the current assembly. These characteristics include: component number in the current assembly; name of the component (either a sub- assembly or a part name in the part database); options selected if the component corresponds to a record in the part database; and a set of variables stored according to logical variable type (see Example 2) which completely record the component's logical condition in relation to the current assembly. In the space plan design database, other records are stored which record the geometry of the building shell,

which has been imported via DXF. DXF and IGES are industry standard file formats used for transporting or converting CAD files between CAD and other applications.

d. TJsam Database.

This is a temporary database created whenever a tile, interior or cluster assembly is being designed. It records a small number of crucial pieces of information for each record in the design database. The TJsam database is used for rapid indexed searches during design for such information as: component number; destination number (the component number of the component the current component is attached to); the logical type of component; the deletability variable; which vector of the component is attached to which vector of the destination component; graphic number; parametric graphic values; location and orientation o the component in the assembly space; hot rectangles (areas in the assembly space where the component can be digitized and made active); and other information accessed frequently. Appendix C:l-2 shows details of the structure and initialization of the T-isam database.

PHframe Database.

This is a temporary database created whenever an interior assembly is being designed. In the interior assembly most components are assembled accordi to the point to point alignment of their connection vectors only in so far as to

determine the relative orientations of their component coordinate systems in relatio to the interior component system (and therefore in relation to one another). This alignment determines the axial rotations of any component in the interior assembly; however, the actual locations of most components is subject to some variation and is determined by how accurately a user digitizes within the graphic space. In orde to prevent logical errors in these user digitizations, it is helpfiil to limit the range o these digitizations geometrically. This prevents two components from occupying the same physical space or from being assembled out of restricted alignment.

Under these conditions, component position along from one to three axes of the assembly coordinate system is not fixed, yet must be bounded. These boundaries form segments along the coordinate axes which correspond to legal, or allowed, axial positions of insertion. The intersection of three sets of legal axial positions forms the set of legal points of component insertion. To track the set of legal points of component insertion into an interior assembly by component logical type, the software uses the PHframe database.

The records in the PHframe database correspond to matrices which track the status of various cubic segments in space in the interior assembly coordinate system. This status includes information such as whether or not the cubic volume referenced by the PHframe record matrix is occupied by some portion of some component, and if so by which logical type of component. Each of the records in the PHframe database corresponds to a component in the interior design database know logically as a phantom frame. Every other component in an interior is attached serially (in the manner of a branching tree) to some component which is

attached directly to a phantom frame (the root of the tree). The records in the interior T_isam database record the component number of this phantom frame for each component which is not a phantom frame. This phantom frame is known as the destination frame of the component.

An Interior Typical assembly is bounded by a contiguous assembly of phantom frames which are assembled to one another directly or through phantom connectors which provide angular variation at the point of assembly. These phantom frames may be thought of as rectangular segments of a plane assembled t form a fence which "corrals" the Interior Typical assembly. These phantom fram and connectors are well ordered in the sense that logically they all point in the same direction (for example, to the left). Because of this, the software can easily access the phantom frames in a group, compiling the information in their associate PHFrame database records into a single logical representation of the three dimensional space associated with that group of phantom frames. When inserting an interior component into an assembly, the group of phantom frames is formed which might possibly affect or be affected by this insertion. This assembled information constrains both which logical and physical types of components may currently be inserted and which locations and orientations are legal for these legal insertions. This information is set through the use of ACTION variables and automatically when any interior component is made active. Both of these methods are shown in the source code examples in Appendix C.

The design tool for systems furniture uses the following Default Database

a. Default Database.

This database is project specific and records user selectable properties of the design which should be automatically selected during menu traversal. The index is by menu number (i.e., on menu #5100 make selection #7 automatically). As many as ten selections can be defaulted for a given menu. If more than one selection is defaulted, the menu does not auto-select but displays only the defaulted selections.

Database Interaction:

The databases reference one another through the following information:

Part Database: * Part Number

* Geometry Number (Graphic)

* Option Numbers

Geometry Database * Geometry Number (Graphic) Option Database * Option Numbers Menu Database * Menu Number

* Output Part Number and Sub-Assembly Number

Crr Database * Sub-Assembly Number Design Database * Component Number

* Part Number or Sub-Assembly Number

T isam Database * Component Number

Default Database * Menu Number

PHframe Database * Component Number

It is important to note that the temporary databases described above (the TJsam and PHframe databases) are created and modified whenever the relevant design database is being worked on. The contents of these temporary databases is determined essentially completely by referring to the design database and the constant databases. These temporary databases are preferably deleted whenever t design process is terminated.

Example 2 Variables

Variables in the software are each of exactly one of seventeen logical classes which govern the way the variables are used:

a. Action Variable.

If while traversing menus one of these variables becomes non-zero, the Inference Engine performs a specific action. These action variables include: 1. ACTCLOSE. Set all closure variables to zero.

2. ACTZERO. Set all zero-able variables to zero.

3. ACTOUT. Add a record to the design database.

4. ACTJHIGH. Calculate the maximum vertical segment available on a cluster frame to hang interior components by logical class of interior component and write these

values into the set of variables 1XVERT01 through 1XVERT30. Alternatively, c_tlculate whether or not interior components can be hung at the defaulted height b logical type and write 1 or 0 (yes or no) into the set of variables 1XVERT01 through 1XVERT30.

5. ACTVERTl. Same as ACTHIGH but only for logical type one (lXVERTOl).

6. ACTFLOOR. Calculate the maximum vertical segment available from the floor for a given width and write the value into the variable lXVERTOl.

7. ACTUNDF5 and ACTUNDF7. Turn off global defaults referred to by the values of these variables (in the menu number ranges 5000 + variable value and 7000 + variable value).

Closure Variable.

These variables are saved with all design database records and record whether or not a specific operation has been performed to the component (they close off the possibility of performing this operation again).

c. Quadrant Closure Variables.

These variables are saved with cluster design database records and record whether or not a specific operation has been performed to a geometric quadrant of the component.

d. Local Default Variables.

These variables govern the automatic selection of operations on some menus according to their values and are stored in the header record of each desig database. They can be changed by the user through the User Commands.

e. OC and 1C variables.

These variables are saved with design database records in cluster assemblies. The OC variables are zero-able while the 1C are not.

01 and II variables.

These variables are saved with design database records in interior assemblies. The 01 variables are zero-able while the II are not.

g. OT and IT variables.

These variables are saved with design database records in tile assemblies.

The OT variables are zero-able while the IT are not.

h. 0A and I A variables.

These variables are saved with all design database records. The OA variables are zero-able while the IA are not.

i. OX and IX variables.

These variables are not saved with any records, but are used to make expert decisions during menu traversal. The OX variables are zero-able while the IX are not.

j. 8_, 4_ and 2_ variables.

These variables are saved with essentially all design database records. They record the values of specific variables in the records which correspond to components attached to connection vectors 1-8, or 1-4 or 1-2 on the current component.

These variables as a whole, then, are sufficient to completely determine the variable aspects of the relation of any component to its assembly, to produce the set of possible logical operations at any point in the design process and to prevent operations which are not possible.

Example 3 Menus and Menu Traversal

The records in the menu database record the expert system logic which governs the design process in terms of menu traversal and, when stored with a design database record, define the variable characteristics of a component. These are highly compressed variable length records which when loaded are de¬ compressed into menu structures. Appendix B includes listings of representative menus. The menu structures each contain multiple, nested copies of several othe structures:

a. DMvar (Change Menu Variable).

This structure records an expert system command to change a given variable. The possible change is =, + =, -=, *=, /=, and the possible modifying value is either an unsigned short integer or the value of another variabl (which is an unsigned short integer).

b. IFJDMvar (If Then Change Menu Variable).

This structure records an if hen condition which if true will cause an embedded DMvar structure to be executed. The condition is in the form if_variable_condition_value- then_DMvar, where condition can be = =, ! = , < =

< < , > =, > > and value can be either an unsigned short integer or the value o another variable.

c. IFcon (If Condition then Action).

These structures contain a series of one or more (up to ten in the preferre implementation) if_variable_condition_value's which are AND'ed together. If the result is true, the return value from the evaluation of this condition is true (a positive value), otherwise the return is zero.

d. MselAct (Menu Selection Action).

These structures occur with some menu selections and are evaluated and acted upon if the given selection is taken (or, in the case of traversal of the menus which set defaults in the default database, if the selection is selected OR unselected). Each MselAct will contain some of the following information:

1. DMvar(s). Executed immediately upon selection.

2. IF_DMvar(s). Executed immediately upon selection. 3. IFcon(s). Checked when menu is loaded. If true then this selection cannot be taken and will not be displayed.

4. IFcon(s). Checked upon selection. A true IFcon condition followed by a non-zero ACTOUT variable causes a component to be added to the design database with the current variable values.

5. DMvar(s). Executed after IFpart(s).

6. IF_DMvar(s). Executed after IFpart(s).

7. IFcon(s). Checked just before loading the next menu. If true then change the next menu number to the returned value.

8. part(s). Component numbers indicated by IFpart(s) retur value(s).

9. DMvar(s). Executed upon un-selection.

10. IF_DMvar(s). Executed upon un-selection.

The menu structure itself, then, is organized as follows:

a. Menu Number. b. Flags. These are integers which indicate: single or multiple defaults allowed for this menu; change the men selection text according to the orientation of the active part, or of the destination part; user can digitize new active item, quadrant, or distance; user can switch from plan to elevation in an interior. c. Selections. Each selection also has flags

(these indicate: next menu number; display help number associated MselAct number), d. Help Text. e DMvar(s). Executed upon loading the menu. f. IF_DMvar(s). Executed upon loading the menu. g. IFcon(s). Executed upon loading the menu. If true the automatically take the selection corresponding to the returned value, h. MselAct(s). Execute upon menu selection (or un- selection).

The menus are broken down into logical categories according to menu number as follows:

1 - 5000 Menus which cannot be defaulted. These menus contain the primary expert rules governing the inter-relation of components in design. These menus are traversed during the design process. 5001 - 7000 Menus which are used to set defaults (where each menu has selections corresponding to a set of options available for a record in the option database). These menus are traversed during the process of setting project defaults. These menu numbers correspond to option numbers in the option database. 7001 - 8000 Menus which are used to set defaults (where each menu coπespond to a design constraint other than the automatic selection of part options). These menus are traversed during the process of setting project defaults.

8001 - 9000 Menus which are used to set defaults (where each menu has selections coπesponding to a set of sub-options available for a record in the option database). These menus are traversed during the process of setting project defaults. 15001-19000 Menus whose selections coπespond to menus in the range 5001 -

9000 but whose selections will be automatically made if a default has been set in this lower range. These menus are traversed during the design process. 19001-25000 These menus function in the same manner as the menus in the range 15001 - 19000.

The flow chart in Figure 5 illustrates the logic and process of menu traversal. Referring to Figure 5, in setting the design environment, check:

1. In setting defaults, whether single or multiple defaults are allowed

2. For correct selection of text according to the orientation of the active or destination component;

3. What kind of digitization is allowed in the menu (only select i b select and un-select?): 4. What kind of digitization is allowed in the graphic area;

5. whether a selected component is the Active Component or a new choice of Active Component (consider the quadrant of the Active Component; horizontal or vertical distance on the active component) ; an

6. Whether switching between interior plan and elevation views is allowed.

Appendix B includes several examples of menu structures. Compare the menu description below (from Appendix page B:5-7) with the corresponding scre shot illustrated in Figures 3 and 4 which illustrate the same menu for the same Active Component but with different displayed options, corresponding to the assembly configuration, illustrated in the screen display. The corresponding men (# 18) is encoded as follows:

Menu #12

Uflag 1: l NSEW: sub type B Uflag 2: 1 UNDEFINED

OXCOMPAR = C

IF (81HEIGHT 8_HEIGHT) THEN OXCOMPAR ++ 1 IF (82HEIGHT 8_HEIGHT) THEN OXCOMPAR ++ 2

Q Select Next Item To Be Attached To This Frame

1 Carpet Grippers

2 Electrical Items

3 Structural Item on West

4 Structural Item On East

5 Telephone/Data Symbol

6 Tile ^" Face Assembly On North

7 Tile Face Assembly On South S Transaction Surface

9 Typical Interior On North

10 Typical Interior On South

11 User commands

Act #1

1ACONDES «= 25 1AC0NCUR « 1 ACTCLOSE — 1 CLOSEO «= 1 IF (OAWIDTH «= 30) THEN OALTGEO «= 1 IF (OAWIDTH — 36) THEN OALTGEO — 2 IF (OAWIDTH «= 42) THEN OALTGEO ■» 3 IF (OAWIDTH «= 48) THEN OALTGEO — 4 IF (CLOSEO—1) THEN CANNOT SELECT IF (1XSPACE»0) THEN CANNOT SELECT IF (1AWILDCD—0) THEN Part #1 G1190. Part 1: G1190. ACTOUT «= 1

Act #2

OXHEHORY =» QCLOSEBA ACTCLOSE — 1 QCLOSEBA «« OXMEMORY IF (86HEIGHT»0) THEN CANNOT SELECT IF (87HEIGHT»0) THEN CANNOT SELECT IF (QCLOSEBA«=15) THEN CANNOT SELECT IF (1CP0WER-«1) THEN Goto Menu #202

Act #3

ACTZERO ■* 1 ACTCLOSE « 1 1AC0NDES = 1 IF (81HΞIGHT»0) THEN CANNOT SELECT

Act #4 ACTZERO ■ ACTCLOSE

1ACONDES == 2 IF (82HEIGHT»0) THEN CANNOT SELECT

Act #5 ACTCLOSE == 1

Act #6

ACTCLOSE =» 1 1ACONDES == 8 CLOSE3 == 1 1ACONCUR — 6 IF (CLOSE3==l) THEN CANNOT SELECT

Act #7

ACTCLOSE « 1 1ACONDES « 5 CLOSE4 »« 1 1ACONCUR =- 6 IF (CLOSE4—1) THEN CANNOT SELECT

Act #8

ACTCLOSE == 1 1ACONCUR == 1 1ACONDES == 3 CLOSES = 1 OXEVENTl — 0 0XEVENT2 — 0 0XEVENT3 — 0 IF (OAWIDTH «= 24) IF (21FWIDTH «= 36) IF (22FWIDTH -= 36) IF (OAWIDTH «= 30) IF (21FWIDTH = 30) IF (22FWIDTH — 30) IF (OAWIDTH — 36) IF (21FWIDTH — 24) IF (22FWIDTH — 24) IF (CLOSE5—1) THEN CANNOT SELECT IF (DEFTPCAP—1) THEN Goto Menu #209 IF (OXEVENTl — 3) THEN 0X60TRAN 1 IF (OXEVENTl =» 5) THEN 0X60TRAN 2 IF (OXEVENTl — 7) THEN 0X60TRAN 3 IF (0XEVENT2 — 3) THEN 0X60TRAN 1 IF (0XEVENT2 ■— 5) THEN 0X60TRAN 2 IF (0XEVENT2 ■=* 7) THEN 0X60TRAN 3 IF (0.XEVENT3 ~ 3) THEN 0X60TRAN 1 IF (0XEVENT3 — 5) THEN 0X60TRAN 2 IF (0XEVENT3 — 7) THEN 0X60TRAN 3 IF (OXCOMPAR ■— 0) THEN 0X60TRAN 0

Act #9

ACTCLOSE =« 1 IF (CLOSE7-—1) THEN CANNOT SELECT

Act #10 ACTCLOSE = 1 IF (CLOSE8—1) THEN CANNOT SELECT

Act #11

IF (1XSPACE»0)

THEN Goto Menu #93

Example 4 User Digitization of a New Active Component

In the course of menu traversal the user may digitize (select) a new active component from the graphic screen by pressing a mouse button while the mouse is within a hot rectangle (areas in the assembly space where the component can be digitized and made active). For tile, interior and cluster assemblies the location of each hot rectangle is stored in the temporary T_isam database.

Upon digitization, the software retrieves the design database record corresponding to the temporary record which contains the digitized hot rectangle. The part database record corresponding to the design database record is retrieved and used to determine the next menu to be displayed. Zero-able variables are zeroed, and the variable values stored with the design database record are restored. If the assembly being designed is an interior, the PHframe database is referenced to set some variable values which will constrain the design process. The next menu is loaded and displayed.

Example 5 Adding a Component to the Design Database

The addition of a component to the design database requires two conditions. The first of these is a TRUE return value from the evaluation of an IFcon structure in an MselAct structure which indicates that a new component has been determined geometrically, that is, the variables which define its geometric connection to the active item have been set. The second condition is a non-zero

ACTOUT variable value. This condition indicates that a new component also has been determined logically, which is to say that all other variables which define the component's variable characteristics have been set.

Referring to Figure 8, the logic flow can be understood. As illustrated in the flow of Figure 8A the temporary database structure and the current design database structure are initialized. In selecting a component for addition to a cuπe assembly certain information must be stored in the temporary TJsam. As the use makes selections within the menus information is accessed from the knowledge base, i.e., part database record, and geometry database record, in order to fully determine the component. The axial locations and rotations for insertion are also determined using the information from the knowledge base. Once the component fully determined the temporary information which has been compiled is saved fro the TJsam structure to the TJsam database.

The design tool then refers to the T_isam record in order to draw a graphic so that the geometry of the added component is fully determined and displayed. Once the geometry is fully determined selected or pertinent variable values are written into the design database structure which is then saved to the design database. If the component which is being added to is a phantom frame, e.g., interior components in an Interior Typical, the PHframe record is modified. The design database record for the destination component is then modified in orde to reflect the addition. That is, information is exchanged between linked components. The vector values for the destination component are updated to refle the connection of a new component. This record is then saved back to the design

database. The new design database record for the added component is also modified to reflect the connections, i.e., changes to the vector variables. And this record is also saved.

If an activatable component is the added component the graphic will be updated so that the added component is the Active Component. Otherwise, the original component which was added to will remain the Active Component. This process of addition is generally true for any type of addition of components. However, in the case of a midrun insertion where one component is added between linked components a special routine must be run which updates the database records for all three affected components as well as shifting the assembly over in space to reflect the addition of the midrun component.

Example 6 Design Rule Check

The design rule check (DRC) involves a check of the assembly design for compliance with local design rules and global design rules. The local design rule check inspects the individual records for each component in the assembly to make sure that each component is configured properly and that the components comply with the local rules defining coπect design. Most parameters of individual components are constrained by the design tool to be configured properly during selection and connection so the local design rule check should find few, if any rule violations.

An example of local rule compliance made by the DRC is completeness o an assembly. In order to verify the completeness of an assembly, the DRC check that all connections in the assembly which must have been used to connect or be connected to another component have been used.

The global rules analyze the assembly in its entirety since these rules loo for proper interaction of the components as an assembly and not just the characteristics of individual components. The design rule check (DRC) looks at a assembly globally to check a number of properties and conditions which must exis for an operational, i.e., coπect, design. The DRC cycles through the T_isam database and develops information about the design on a global level. Global design rules checked include physically unstable assemblies (designs which will collapse under gravity, for example) and logically unstable assemblies (a electrical circuit design which draws too much power or is discontinuous, for example).

Accordingly, global design rules check properties (DRC) power characteristics such as the loading of a power circuit within an assembly, the continuity of power lines within a powered circuit, the structural coπectness of a design, and the support for transaction surfaces, described below. Power characteristics require the testing of all power circuits for continuity and loading a floor level and belt line of an assembly. Also, checked is the relative heights of connectors and frames to ensure they coπespond coπectly.

Although most components can be linked both logically and physically with a single other component, this is not always the case, i.e., a component may

have to be physically linked to more than one component. For example, a transaction surface may extend across and be secured to more than one frame or other component. A transaction surface is a surface such as a desktop which is attached to and extends out from a frame or frames. If the transaction surface is longer than the width of one frame it must be supported and attached to each of th underlying frames. When adding a transaction surface to an assembly, the design tool allows for one destination component for the transaction surface, or, in other words, the transaction surface is logically entered as linked to one other componen even if there is an incomplete match in physical reality and the transaction surface actually needs to be connected physically to an additional component. There is no check during the design process of the structural coπectness of the assembly for a transaction surface which is longer than one frame since information regarding linkages between components is only exchanged between source and destination components during addition of components.

After performing the design rule check, the design tool can make selected changes and additions to the design database, a process which can be fully automated or performed manually, with or without computer assistance. Such automatic changes include adding end or top caps, height change packages or wiring harnesses where the design defaults for the assembly allow only a single choice for a missing component. The transaction surface check process will detect all frames which do not support the transaction surface and if possible will change appropriate end caps to end caps with transaction surface support.

There are three results of the DRC, i.e., a clean pass, a warning, or a failure. If the assembly checked satisfies all design rules both local and global th the DRC passes on the design and the design has a clean pass. If there is a desig flaw which allows the assembly to be constructable a warning may be given. A warning is treated by the system as a clean pass but notifies the user that there is design fault. The third result of the design rule check (DRC) is a failure. If an assembly fails the DRC returns an appropriate message as to the failure and probable cause of the failure and will not permit some forms of automated output from the checked assembly. If missing components cannot be determined automatically, the design tool will register a DRC failure, which will cause the documentation control portion of the design tool to tag the design as incomplete a prevent production of some forms of automated output. Referring to Figure 2, th bill of materials ends with a "WARNING: CLUSTER(S) in set failed DRC". Referring to Figure 7, a graphic result of the DRC check highlights incomplete frame 11, which is lacking tile surfaces (see Figure ID) and has one end unterminated.

Example 7 Data Structure. Midrun Insertion and Deletion

Each individual record in the design database coπesponding to a respecti component within an assembly includes sufficient information to identify the relationship of the coπesponding component to other components in the assembly. In a present prefeπed embodiment of the invention the interconnection of components is defined by the linkages between the components.

Each record of the design database contains information completely and independently defining the state of the coπesponding component. This informatio controls the rule based design and consequent graphical and menu display for an activatable component. For a non-activatable component the state information relates to the rule based design of the activatable component to which it is connected. The variables which contribute to the definition of the logical state of the component are closure variables, quadrant closure variables, and identity information for that component.

The physical state of a component relates to the geometric relationships of that component to all other components connected to it. The variables which help define this state include the 8_, 4_, and 2_vector variables and destination component number. The vector variables for a particular record indicate the vector linkages of the coπesponding component and of those components linked to the coπesponding component.

Each record in the design database for a component includes three types o information: information relating to the linked list of geometric connectivity, information shared by adjacent components, and other state information. The examples above disclose additional information regarding variables and design database structure. The information relating to the linked list of geometric connectivity is that information which identifies the component number of the coπesponding component and the component number of the destination component.

The information shared by adjacent components includes the vector variable information and closure variables. The linkage of one component to another results in the newly added component being designated the source component and the component which it is linked to designated as the destination component, as refeπed to above. The record coπesponding to a component contains the value of the vectors at which it is linked on the coπesponding component or components and the vector values on itself to which other components are linked.

The linkage of one component to another causes closure variables on bot the source and destination component to change. A component has a set of closu variables for possible linkage of certain types of component. For example, when an outlet is added to a frame, a closure variable indicating the closure of that position on the frame for outlets is changed to reflect that condition. A similar variable on the outlet component is modified to reflect closure of the position on the outlet.

Quadrant closure variables are variables indicating the overall closure status of a frame based on the addition of components. The quadrant closure variable is incremented every time a quadrant of a frame, for example, is "closed in the sense that no further components may be added. The value of the quadrant closure variable is redundant to other closure variables which are individually specific to particular types of components to be added to a component.

Additional information stored in each record for a component in the design database is information pertaining to the logical state or status for the coπesponding component. This information includes identity information such as, the size and part number of the component. Information relating to the possible deletion of a component is stored as the deletability variable.

Addition of a component involves exchange of information between the source and destination component and modification of the deletability variable to reflect the new logical state of each component. The design database for each component can be accessed and operated on in a random access fashion. That is, components may be added to, deleted from or modified in the database without regard to the order which these operations are performed to the assembly. The deletability of a component controls the response of the system to a command to delete that component. The process of deletion is refeπed to above in the section on the design process under the subsection "b. Deleting Components".

Every time an active component is linked to another active component the deletability of the two components linked is incremented by one. An active component with no links has a deletability of zero. Therefore, only those active components which are linked to two other active components will have a deletability greater than one.

The components having a deletability of greater than one are linked to two or more components of equal hierarchical value, i.e., two active components, and are deleted according to method two. In a prefeπed embodiment of the invention,

method two allows for deletion of those components of deletability of two or greater by employing a separate routine which can modify the assembly so the components connected to the deleted component are linked after deletion. Presently, the design tool used for this form of deletion employs a midrun deletio routine.

The midrun deletion routine allows frames, spacers and midrun cabnets linked to two other activatable components on either side to be deleted and the resultant gap be eliminated by connecting the resultant assembly portions. This involves a three step process. First, the midrun routine refers to the record of component linkages and selects the two which must be linked to compensate for t deleted component. Appropriate information, as described above, is then exchanged between the coπesponding records for the two components. The graphical information for the components attached to one of the frames to be linked, as well as the graphic information for that frame, is modified so that the position of the associated portion of the assembly is shifted an amount sufficient t compensate for the deleted frame.

In all other cases of deletion of a target activatable component having a deletability variable value of greater than one the activatable components linked to the target component must be deleted before the target component is deleted. Onc the linked component or components are deleted the target component will have a deletability variable value of one and can be deleted by method one.

A midrun insertion routine is used by the expert system to take advantage of the modular, random access capacity of the records for the components in an assembly. That is, using a process similar to the one described above for the midrun deletion routine certain components (e.g., frame connectors, frames, and midrun cabnets) can be added between two existing frame components. The insertion is made to the records in the design data base with the appropriate exchange of information and the graphic position of portions of the assembly are modified to reflect the addition.

Example 8 Cluster Assembly Formation

Figures 3, 4 and 9-29 show a sequence of displays, i.e., a series of screen dumps, which show the progress of a simple design session. The session will be summarized in the following paragraph and then discussed in detail below. The session begins by reviewing default values, then a series of menus presents available actions and choices. Starting with a 48" frame, a second 48" frame is added, then a 30" work cabinet. The center frame is built up with one of several preselected tile face assemblies, Tile Typicals, on the south and a predesigned Interior Typical on the north. Figures 1 and 2 illustrate some of the automated output generated from this simple design (two and three dimensional CAD drawings and a bill of materials). Appendix B includes several representative menus, including those displaying screens in Figures 3, 4, and 9-29. Compare Figure 29 with B-4 or Figures 13, 3, 23, 25, 4, and 28 with B-5-7.

Figures 9 and 10 show two default selection menus. In Figure 9 the use is given the option of selecting whether or not the frames are powered or nonpowered. In accordance with this type of default selection if the user selects the powered or nonpowered option the inference engine will make the selection a the appropriate time without any user input. Otherwise during selection of each frame a menu will appear asking whether or not the frame should be powered or nonpowered. In Figure 9 the user has selected powered. Likewise, in Figure 10 the user has selected that all frames in the cluster assembly have a height of 70" .

After selecting default values the user is given a choice of structural elements to add. As shown in Figure 11 the user is given the choice of adding a frame or a wall strip. In Figure 11 the user selects a frame.

Once the class of component is selected, e.g., a frame, the user is presented with menus of selectable constant characteristics for this classification o element so that a final component is determined. In Figure 12 the user selects th the width of the frame should be 48". The menu for the height of the frame was auto selected so the height of the frame is 70" without any user input.

As shown in Figure 13 after the component is fully determined a graphic representation of the component is displayed in the graphic window. If the component added is an activatable component, after it is added that added component will be the cuπently Active Component. The menu displayed will be the active menu for that Active Component. Figure 13 illustrates the user makin

the selection of adding a structural item on the west side of the Active Component.

After selecting the option of adding a component onto the west side a menu displaying the possible components to be added onto the west side is displayed as illustrated in Figure 14. The user makes the selection of adding a frame. After the user selects the type of component menus are again displayed which allow the user to select the characteristics of the component to be added. As shown in Figure 15, the user selects that the width of the frame to be added on the west side of the first frame is 48".

Now that this second frame is fully defined it appears in the graphical window as the Active Component. Further, the menu displays a series of possible options in connection with this cuπently Active Component. These selections are either User Commands or additions to be made to the Active Component as shown in Figure 3.

Since the user selects to add a structural component from the menu illustrated in Figure 16 the next menu displays the options for this classification of component. From these structural item options the user selects a support cabinet.

Once the user selects a support cabinet the design tool presents menus from which the user makes selections which fully define the support cabinet until the support cabinet is displayed in the graphic environment and made the Active Component as illustrated in Figures 17-22. In Figure 22 the user digitizes a frame which becomes the Active Component as illustrated in Figure 23. In Figure 23 the

option menu for this Active Component is illustrated. The user selects to add a Tile Face assembly on the south side of the active frame. A user response to this selection is illustrated in Figure 24. The user is given the option of selecting from existing Tile Typicals or to make a new Tile Typical or Tile Assembly. The user selects A0A0A0A0 as the Tile Typical to be added.

After addition of the Tile Typical the user is returned to the active menu for that frame. As illustrated in Figure 25 the option of adding a Tile Face Assembly on the south has been eliminated by the inference engine. Accordingly, the user selects to add a Interior Typical on the north.

Again, the user may select an existing Typical as shown in Figure 26. The user selects an Interior Typical and it is added to the assembly as shown in th graphical window in Figure 4. The menu for the frame as an Active Component i illustrated in Figure 4 from which the user elects to add a Tile Face Assembly, i.e., Tile Typical on the north. Figures 27 and 28 illustrate the addition of a Tile Typical. In Figure 28 the user selects user commands and initiates DRC upon exit from the assembly design.

The DRC is initiated automatically by the user selecting end from the action menu for user commands as shown in Figure 29. As discussed above the Figure 7 illustrates a DRC failure with a highlighted item showing a completeness failure.

As will be understood by those skilled in the art, many changes in many aspects of the process described above may be made by the skilled practitioner without departing from the spirit and scope of the invention, which should be limited only as set forth in the claims which follow.

IF ⁽ 1 CIRCUIT*-! )

THEN SELECT # 1 4 Circuit

IF .1CIRCUIT—2)

THEN SELECT #2 4 Circuit, Shielded

Q Power Circuit Cations, Frame

1 4 circuit 10=15078 ->Menu Ul= 1 Act#

2 4 Circuit, Shielded 10=15078 ->Menu Ul= 2 Acts

Act #ι

OADEPTH ==* 24

IF (8_HEIGHT==38&&0AWIDTH==24)

THEN Part #1 E1110.3824E

IF (8_HEIGHT==38&&0AWIDTH==30)

THEN Part *2 E1110.3830E

IF (8_HEIGHT==38&&0AWIDTH=»36)

THEN Part #3 E1110.3836E

IF (8_HEIGHT==38&&0AWIDTH== 2)

THEN Part #4 E1110.3842E

IF (8_HEIGHT=-38&&0AWIDTH==48)

THEN Part #5 E1110.3848E

IF (8_HEIGHT=-54&&0AWIDTH==24)

THEN Part #6 E1110.5424E

IF (8_HEIGHT=54&&0AWIDTH==30)

THEN Part ήl E1110.5430E

IF 8_HEIGHT=-54&&0AWIDTH=-36)

THEN Part #8 E1110.5436E

IF 8_HEIGHT=54&-_0AWIDTH=«42)

THEN Part #9 E1110.5442E

IF 8_HEIGHT=»54&&0AWIDTH—48)

THEN Part #10 E1110.5448E

IF (8_HEIGHT=70&&0AWIDTH«24)

THEN Part #11 E1110.7024E

IF 8_HEIGHT=»70&&0AWIDTH—30)

THEN Part #12 E1110.7030E

IF 8_HEΣGHT=70&&0AWIDTH—36)

THEN Part #13 E1110.7036E

IF 8_HEIGHT=-70&£OAWIDTH—42)

THEN Part #14 E1110.7042E

IF 8 HEIGHT=-70&&0AWIDTH= ■48)

THEN Part #15 E1110.7048E

IF 8 HEIGHT=-864&0AWIDTH= •24)

THEN Part #16 E1110.8624E

IF 8 HEXGHT=»86__&0AWIDTH= »30)

THEN Part #17 E1110.8630E

IF (8_HEIGHT=-864&0AWIDTH=-36) THEN Part #18 E1X10.8636E

8_HEIGHT=»86&&0AWIDTH=» 42 )

THEN Part #19 E1110.8642E

IF 8_HEIGHT=-86&&0AWIDTH—48 )

THEN Part #20 E1110.8648E

IF OXCHANGE—1)

THEN Goto Menu #187

Appendix Page B-l

Act #2 OADEPTH == 30

^• 8_HΞIGHT—38ffΣiOAWIDTH-^ _^ 24) THEN Parr si E1110.3824L IF (8_HΞIGHT=38&&0AWIDTH==30) THEN Parr #2 E1110.3330L IF (8_HEIGHT—38&_iOA IDTH==36) THEN Parr #3 E1110.3836L

IF 8 HEIGHT=38&&0AWIDTH==42)

THEN Parr S4 E1110.3842L

IF 8 HEIGHT=38&&0A IDTH= 8)

THEN Par #5 E1110.3848L

IF 8_HEIGHT=54&&0AWIDTH=24 )

THEN Parr #6 E1110.5424L

IF (8_HEIGHT—54&-_0AWIDTH=30)

THEN Parr Hi E1110.5430L

8 iEIGHT—54&&0AWIDTH==36) THEN Parr #8 E1110.5436L IF 8_HEIGHT=»54&&0AWIDTH=«42) THEN Parr #9 E1110.5442L

IF 8_HEIGHT—54&&0AWIDTH=»48)

THEN Parr #10 E1110.5448L F 8_HEIGHT=70&&OA IDTH=»24 )

THEN Parr #11 E1110.7024L

IF 8_HEIGHT=7OSS0AWIDTH=»30)

THEN Parr #12 E1110.7030L

IF 8 HEIGHT-=70&-_0AWIDTH= •36)

THEN Parr #13 E1110.7036L

IF 8 HEIGHT=«70&-_0AWIDTH= *42)

THEN Parr #14 E1110-7042L

IF 8_HEIGHT=70S__0AWIDTH=-48)

THEN Parr #15 E1110.7048L

Parr E1110.3324L

Parr 2: E1110.3830L

Parr E1110.3836L

Parr E1110.3842L

Parr E1110.3848L

Parr 6: Ξ1110.5424L

Parr 7; E1110.5430L

Parr 8: E1110.5436L

Parr 9: E1110.5442L

Parr 10: Ξ1110.5448L

Part 11: Ξ1110.7024L Appendix Page B-2

Appendix Page B-3

Q Action Menu

Help #1

If this option is selected in error, press the

ESC key to return to this menu.

Act #1

0XACTION == 1 IF ,1XNEWNAM=1) THEN CANNOT SELECT

Act #2 0XACTION = 11

Act #3 0XACTI0N = 21

Act #4

IF (0X00000O=»O)

THEN CANNOT SELECT

Act #5

0XSAVEHE = 1 1XNEWNAM =» 0

Appendix Page B-4

.ι≤x_V: suo :v e

.'flag 2 : I "..DEFINED XCOMPAR == 0

:" (81HEIGKT == S_HΞIGHT. THEN OXCOMPAR — 1 F (82HEIGKT == S HEIGHT) THEN OXCOMPAR — 2

2 Select Next Item To Be Attached To This Frame

1 Carpet Grippers

2 Electrical ^" Items

3 Strucrural Item On West Structural Item On East

5 Telephone/Data Symbol

6 Tile Face Assembly On North

7 Tile Face AssemDiy On South 3 Transaction Surface

9 Typical Interior On North

10 Typical Interior On South

11 User Commands

Act #1

1ACONDES == 25 1ACONCUR == 1 ACTCLOSE == 1 CLOSEO == 1 IF (OAWIDTH == 30) THEN OALTGEO == 1 IF (OAWIDTH == 36) THEN OALTGEO == 2 IF (OAWIDTH == 42) THEN OALTGEO == 3 IF (OAWIDTH == 48) THEN OALTGEO == 4 IF (CLOSE0»1) THEN CANNOT SELECT IF (1XSPACE»0) THEN CANNOT SELECT IF (1AWILDCD=0) THEN Part #1 G1190. Part 1: G1190. ACTOUT = 1

Act #2

OXMEMORY == QCLOSEBA ACTCLOSE == 1 QCLOSEBA <== OXMEMORY IF ( 86HEIGHT»0 ) THEN CANNOT SELECT IF ( 87HEXGHT»0 ) THEN CANNOT SELECT IF (QCLOSEBA=15) THEN CANNOT SELECT IF ( 1CP0WER==1 ) THEN Goto Menu #202

Act #3

ACTZERO = 1 ACTCLOSE == 1 1ACONDES == 1 IF (81HEIGHT»0) THEN CANNOT SE.LECT

Act #4

ACTZERO == 1 ACTCLOSE == 1- Appendix Page B-5

_ACO D£S == IF (82HEIGHT»0 ) THEN CANNOT SELECT

Act #5 ACTCLOSE == 1

Act #6

ACTCLOSE = 1 1ACONDES == 8 CLOSE3 = 1 1ACONCUR == 6 IF (CLOSE3=l) THEN CANNOT SELECT

Act #7

ACTCLOSE = 1 lACONDES = 5 CLOSE4 = 1 1ACONCUR = 6 IF (CL0SE4=1) THEN CANNOT SELECT

Act #8

ACTCLOSE == 1 1ACONCUR = 1 lACONDES = 3 CLOSES = 1 OXEVENTl = 0 0XEVENT2 = 0 0XEVENT3 = 0 IF (OAWIDTH = 24) IF (21FWIDTH = 36) IF (22FWIDTH == 36) IF (OAWIDTH = 30) IF (21FWIDTH = 30) IF (22FWIDTH = 30) IF (OAWIDTH = 36) IF (21FWIDTH = 24) IF (22FWIDTH = 24) IF (CL0SE5=1) THEN CANNOT SELECT IF (DEFTPCAP=1) THEN Goto Menu #209 IF (OXEVENTl = 3) THEN 0X60TRAN 1 IF (OXEVENTl = 5) THEN 0X60TRAN 2 IF (OXEVENTl = 7) THEN 0X60TRAN 3 IF (0XEVENT2 = 3) THEN 0X60TRAN 1 IF (0XEVENT2 = 5) THEN 0X60TRAN 2 IF (0XEVENT2 = 7) THEN 0X60TRAN 3 IF (0XEVENT3 = 3) THEN 0X60TRAN 1 IF (0XEVENT3 = 5) THEN 0X60TRAN 2 IF (0XEVENT3 = 7) THEN 0X60TRAN 3 IF (OXCOMPAR = 0) THEN 0X60TRAN 0

Act #9

ACTCLOSE = 1 IF (CLOSE7=l) THEN CANNOT SELECT

Act #10 ACTCLOSE = 1 IF (CLOSE8=l) THEN CANNOT SELECT

Act #11 Appendix Page B-6

IF (1XSPACE»0) THEN Goto Menu #93

Appendix Paee B-7

Uflag 2: 1 UNDEFINED

Q Select Next Component To Be Attacned To This Phantom Frame

1 Chair Next To Frame

2 Coat Bar And Shelf

3 Lateral File, Freesranding

4 Lateral File, Suspended

5 Pedestal, Freesrandinσ

6 Shelf

7 Storage Cabiner

8 Tabled Freestanding

9 Work Surface 10 User Commands

Act #1

IF (0X000000=0)

THEN CANNOT SELECT

Act #2

0XGOTO == 75

IF (1IWIDTH=36)

THEN CANNOT SELECT

IF (1IWIDTH= 2)

THEN CANNOT SELECT

IF ( ₀ XC _O AT03= _O&& 0X _C OAT06=O&&0XCOAT07=O)

THEN CANNOT SELECT

Act #3

ACTCLOSE = 1

IF (1XFREE27« _30&& 1XFREE ₄ 2«30£&1XFREΞ54«30)

THEN CANNOT SELECT

Act #4

1XDITEM = 16 ACTHIGH = 1 1XHITEM == 14 0XINTIOR = 1 IF (1IWIDTH=36) THEN CANNOT SELECT IF (1IWIDTH=42) THEN CANNOT SELECT IF (0XSLATOK=O) THEN CANNOT SELECT

Act #5

IF (1XFREE24«15&&1XFREE27«15)

THEN CANNOT SELECT

Act #6

1XDITEM = 14

ACTHIGH = 1

1XHITEM = 8

IF (OXSHLFOK—O)

THEN CANNOT SELECT

Act #7

0XINTIOR = 2

1XDITEM = 14

0ISTRCAB = 1

IF (1XSTORAG == 1) THEN ACTHIGH == 1

IF (1XSTORAG = 1) THEN 1XHITEM == 16

IF (1XSTORAG == 0) THEN 1XHITEM == 16

Appendix Page B-8

IF (1XST0RAG == 0) IF (0XSTOROK==0) THE ^{N AC} THIGH ~ 8_HEI _G HT THEN CANNOT SELECT

Act #8

IF (0X000000=0 ₎

THEN CANNOT SELECT

Act #9

OXMEMORY == 4

1XDITEM == 60 ACTFLOOR == 1

OXPENSOK == lXVERTOl ACTCLOSE == 1 IF (0XWORKOK== ₀₎ THEN CANNOT SELECT

Appendix Page B-9

Uflag 2: 1 UNDEFINED OXSAVEHE == 0

Q Diσitise Workinσ Item Or Make Menu Selection

Help #1

If this option is selected in error, press the

ESC key to return to this menu.

Act #1

OXACTION =- 3 IF (1XNEWNAM—1) THEN CANNOT SELECT IF (0X000O0O=»O) THEN CANNOT SELECT

Act #2 OXACTION 13

Act *3 OXACTION = 23

Act #4

Act #5

IF (lXSPACE—1) THEN CANNOT SELECT IF (1XSPACE=3) THEN CANNOT SELECT

Act #6

IF ( 1XSPACE=2 ) THEN CANNOT SELECT IF ( 1XSPACE=»4 ) THEN CANNOT SELECT

Act #7

1XSPACE =» 4 IF ( 1XSPACE=2 ) THEN CANNOT SELECT IF ( 1XSPACE—4 ) Appendix Page B-10

Acr ss IXSPACE == 3 IF f IXSPACE— 1) THEN CANNOT SELECT IF .1XSPACE==3) THEN CANNOT SELECT

Act S9

OXSAVEME == 3 1XNEWNAM == 0 IF ⁽ 0X000000==O, THEN CANNOT SELECT

Act S10

IF (1XSCLACT!=1)

THEN CANNOT SELECT

Appendix Page B-ll

IF .CCPENCAB»0)

THEN SELECT #4 Peninsula

Q Work Surface oprions

1 Corner 10=17013 ->Menu ϋl= 1 Act?

2 Corner VDT 10=17013 ->Menu ϋl= 2 Act*

3 Mitered 10=17013 -> enu Ul= 3 Act*

4 Peninsula 10=149 ->Menu ϋl= . Act*

5 Recranguiar 10=17013 ->Menu Ul= 5 Act*

Act #1

0AWOR SF -- 1 lACONCUR = 1 lACONDES == 3

IF (1XVERT13 >> 0) IF (1XVERT13 >> 0) IF (1XVERT15 >> 0) IF (1XVERT15 >> 0) IF (1XVERT17 » 0) IF (1XVERT17 » 0) IF (1XVERT19 » 0) IF (1XVERT19 >> 0) IF (1IWIDTH— '30&&0ADEPTH=

THEN CANNOT SELECT

IF flXVERT12=O&-_lXVES.T13==O&&lXVERT14=O&&lXVERT15=O&&lXVERT16 ==0&£ THEN CANNOT SELECT IF (DEFTOPTP—2) THEN Goto Menu s95

Act *2 0AWOR ΞF 2 lACONCUR 1 lACONDES 3

IF (1XVERT19 >> 0) THEN lACONCUR = IF (1XVERT19 >> 0) THEN lACONDES = IF (1XVERT21 >> 0) THEN lACONCUR == IF (1XVERT21 >> 0) THEN lACONDES = IF (0ADEPTH=24&&DEFTOPTP='2) THEN CANNOT SELECT IF .0ADEFTH=24&&1XVERT18=> O&&1XVERT19—0) THEN CANNOT SELECT IF (OADEPTH—30&&1XVERT18— '0&&1XVERT19=»0&&1XVERT20=0&&1XVERT21===. THEN CANNOT SELECT IF (1IWIDTH—36) THEN CANNOT SELECT IF (1IWIDTH—48) THEN CANNOT SELECT IF (DEFTOPTP—2) THEN Goto Menu #96

Act #3

OAWORKSF -"• 3

IF (1XVERT22—0&&1XVERT23—0&&1XVERT24—0&&1XVERT25—0&&1XV ERT26 ==o&__.

THEN CANNOT SELECT

IF (lXVERT24»θδδlXVERT25»θ&&lXVERT24=-lXVERT25&&lIWIDTH'� ��24)

THEN CANNOT SELECT

IF (1XVERT26»0&£1XVERT27»0&&1XVERT26=1XVERT27)

THEN CANNOT SELECT

IF (1XVERT28»0&£1XVERT29»0S&1XVERT28=1XVERT29)

THEN CANNOT SELECT

IF (DEFTOPTP—2)

THEN Goto Menu *97

Appendix Paee B-I2

THEN lACONCUR == 4 THEN lACONDES == 4 THEN lACONCUR == 5 THEN lACONDES == 1

Act #5

OAWORKSF +-■ ^■ 5

IF (lXVERT01==O&&lXVERT06==O&&iXVERT07==O&&lXVERT08==O_.&lXVERT 09== <0&

THEN CANNOT SELECT

IF (DEFTOPTP—2)

THEN Goto Menu #98

Appendix Page B-13

_.t_isam.H */ «/

T isam ISAM structure initializations V

ZSEG T_isa_a_seg[] =

2, S ) SEGMENT 1 INDEX 1 number 4, s ) 2, ε ) 6, _; , s ) 2, 2, 8 )

8, 1, 1

2. 2 r 8 }

9, 1. 1 ) 2, 2. 8 }

10, 2, 8 )

EIDX T_isam_id_c[] =

2, /* KEY length index l */ 0, /* KEY type index l */ 0, /* DUPLICATE flag off V 0, /* NULL key flag off */ 32, /* EMPTY character V

1, /* KUMBER of key segments &T_isam_seg( 0 ] /* POINTER to segment array V

*/

/* NULL r-tree index name _* /

4, /* KEY length index 1 V

0, /* KEY type index l */

0, /* DUPLICATE flag off */

0, /* MULL key flag off V 32, /* EMPTY character V

2, /* NUMBER of key segments V &T_isam_seg [ 1 ] /* POINTER to segment array */ /* NULL r-tree index name */

4, /* KEY length index 1 */

0, /* KEY type index 1 */ o, /* DUPLICATE flag off */ o, /* NULL key flag off */

32, /* EMPTY character _* / 2, /* KUMBER of key segments * / / &T_isam_segf3] /* POINTER to segment array * / * NULL r-tree index name */ ^'

3, /* KEY length index l V

0, /* KEY type index 1 */

0, /* DUPLICATE flag off */

0, /* NUL key flag of V 32, /* EMPTY character V

2, /* NUMBER of key segments / £T_isam_seg[5] /* POINTER to segment array * * / /* NULL r-tree index name * /

3, /* KEY lenσth index 1 */

0, /* KEY type index 1 */

0, /* DUPLICATE flag off »/

0, /* NULL key flag off * / 32, /* EMPTY character */

2, /* NUMBER of key segments &T_isam_seg[7] /* POINTER to segment array /* NULL r-tree index name

Appendix Page C-l

4, /* KEY length index l */

0, /* KEY type index l */

0, /* DUPLICATE flag off */

0, /* NULL key flag off 32, /* EMPTY character V */

2 , /* NUMBER of key segments */ &T_isam_seg[9] /* POINTER to segment array */ /* NULL r-tree index name V

4, /* KEY length index l */

0, /* KEY type index 1 */

0, /* DUPLICATE flag off */

0, /* NULL key flag off 32, */ /* EMPTY character

2, /* NUMBER of key seαments V &T_i-sam_seg[11] /* POINTER to segment array V /* NULL r-tree index name V

*/ /* END of iidx definition */

IFIL T_isam_dat = {

"T_isam", /* root file name */ - /* data file number */

72ι,, /* record length */

288, /* file extension size */

0, /* data file mode */

7, /* number of indices */

256, /* index file extension size */

0, /* index file mode */

T_isam_idx /* pointer to index array */

} /* NULL fields */

Appendix Page C-2

ΞSTRUCT.K

Structures used i the software

struct eo_σs /* Record in geometry database ag;

; s vectorfMAXCONI ; /* vectors

struct part_qs /* Records in the part database

(

COUNT delete_flag;

COUNT classf10] ;

TEXT partrPARTL+1] ;

TEXT desc.DESCL+1] ;

TEXT dvg2 3] ; ΦΓVT dwg [3] ; unsigned char delivery; unsigned cnar lockplug; unsigned cnar obsolete; unsigned char gw; unsigned char gH; unsigned char gD; unsigned char numHistory; unsigned char Itype; unsiσned char UflagC ]; float weight; float volume; float asytia; float comyds; float Fflagι;2] ;

COUNT graphic:

COUNT fixpart;

COUNT actmenu;

COUNT Iflag[4] ;

TEXT var(30+(10*PART_HIΞTORYLEN) ] ;

s ric def_σs /* records in the default database

(

COUNT delete_flag;

COUNT number; unsigned char opt[10][10]; unsigned char suboDtflO] [10] ; unsigned char CDIusedriO] ; unsiσned char Uflag[4] ^" ;

TEXT descf72] ;

}; struct DMvar_σs

{ unsigned char chanσe ; /* 0= 1+= 2— 3*» 4/= unsigned char type; /* which type of var changes unsigned char num; /* which var numner cnanges unsigned char to_type ; /* type of modifier (0=»mteger) unsiσned char to nύia; /* modifier var num or integer value unsiσned char Uflaσ;

Appendix Page C-3

IF _.Mvar cs compare; /* type or comparison cna ge; .-* type of change in mod_var ty e; /* 1st var type nύm; ^' /* 1st var nύmcer comp_type ; /* type of comparator (0==inteσer) comp^nύm; * comparator var num or integer value mod^_type ; * type of var to be changed mod_nύiiι ; * numaer of var to be cnanged to_type ; /* type of to_ value (O∞mteαer) to nύm; /* tό_ modifier var num or integer val

result ; /* if TRUE then return this value useNote ; numcnecj ; /* number of conditions to check howcneci ; /* how to put togetner the conditions /* o -> && them all togetner unsigned char type [ 8 ] ; unsigned cnar numf 8 ] ; unsigned char to_type [ 8 ] unsigned char to~nύm[ 8 ] ; unsiσned char compare [ 8 ] /* how to compare them /* 0 value

/* NOTE: these last five */ /* ι_ value /* vaiues are read into */ /* 2 << value /* this structure using */ /* 3 >> value /* the structure IFcon_in */ /* 4 <= value /* which is also used to */ /* 5 >= value /* write out this info */ /* 6 variable's value /* (it has a pad byte to */ /* 7 variable's value /* to make an even size) */ /* 8 << variable's value /* 9 >> variable's value /* 10 <= variable's value /* 11 >= variable's value

) ^; struct iFccn in σs ( unsigned char compare; unsigned char type; unsigned char num; unsigned char to_type; unsigned char to~num; unsigned char Uflag; ); struct MselAct gs ( unsigned char nuaDMvar; unsigned char numIF_DMvar; unsigned char numlFno ; unsigned char numlFparx; unsigned char numlFgoto; unsigned char numOMvar2; unsigned char numIF_DMvar2: unsiσned char numPart;

Appendix Pa e C-4

struct CIgraph_σs

Appendix Page C-5

COUNT rotZ; float locX; float iocY;

struct Clbase σs

; struct CItile gs {

COUNT delete_flag; COUNT TileSuper; COUNT TileSub; char rev; char lastch; unsigned char opt[10] ; unsigned char subopt[10] ; }; struct CItileA qs {

COUNT delete_flag; COUNT Tnum; COUNT zero; char rev; unsigned char widt ; unsigned char height; unsigned char frame_ s; unsigned char numtile; unsigned char Gtile[5]; unsigned char sup[5] ; unsiσned char sub[5 ; COUNT graphιc[2] ;

struct Gspace gs {

COUNT delete_flag; COUNT number? COUNT Snum; COUNT Citemnum; unsigned char deletable; unsigned char g ; unsigned char gH; unsigned char gD; unsigned char altgeo; unsigned char DrawLay; unsigned char height[4] ; unsigned char Uflag; char DBAinrev; COUNT DBAin;

Appendix Page C-6

COUNT graonic; COUNT rot2; float locX; float locY; float locZ; rect gR; rect ggR;

Ξ~ΣT_1 :em σs /* cluster design database record

struct litem σs /* Interior design database record

{

COUNT delete_flag;

COUNT number;

TEXT Manu_Linef21 ;

TEXT par fPARTL+i] ; unsigned char opt[iθ] ; unsigned char suboptflO] ; unsigned char deletable;

COUNT orddes;

COUNT useKey;

COUNT dircoήl;

COUNT Iflaσ[5] ; unsigned cnar UflaσflO] ; unsigned cnar UvarfMAX_XlA+MAX_X0A+MAX_XlI+MAX_X0I+MAX_XC OSE+ (MAX_XS_*9)+(MAX_X4_*5)+(MAX_X2_*3) ] ;

} ;

struct Titem_σs /* Tile design database record {

COUNT dele e_flag; COUNT numoer; TEXT Manu_Linef2] ; TEXT partrPARTL+i] ; unsigned char opt[Ϊ0] ; unsiσned char subontf10] ; unsiσned char Uflag[11] ; COUNT orddes; COUNT I lag[5]; unsigned char Uvar(MAX_XlA+MAX_XOA+MAX_XlT+MAX_XOT] } struct isam gs Appendix Page C-7

struct PHframe qs

{

COUNT delete_flag;

COUNT number; unsigned char width; unsiσned char height; char used[48][86]

)

struct PHadj_qs

{

COUNT number;

COUNT dist_left;

COUNT dis ~orthog; unsigned char left! unsigned char orthog; unsigned char width;

> ;

Appendix Page C-8

* XINT.C

. _*

- ^■ * The functions in this file acts as the Design Manager fcr the * creation cf Inteπcr Typicaxs. void Dclnterior f )

OoenPrcTϋef() ; upCAD= 6: newActive* 0; curEframe« 0; InFl= 0; CADstatus= 0; OpenPrcTCIO ; openPHframe() ; ord tem-* 0; curltemβ l; numlframe- 0; Leastltem« 1; Oαenltemi) ; NextMenu= EI_M_INT; DoNot£xitlntenor= l; AutoIr.t aop() ; while OoNotExitlnteπor)

Querycursorf C&curP.X. , (&curP.Y. ,&curL,&curi_) ; if (KeyEvent(False,&evnt) )

{ if (evnt.ASCII=»θ&-.evnt.≤canCode—0&&evnt.State>θxff)

{ if (evnt_State>oxff_.&evnt.State<ox2ff) Mbutton= RIGHTB; else Mbutton= LΣFTB; if (Mburtαn«-LETTS) { if (upCAD—O) { if (cur«sel>-2) { if (curMsel=—l) DisMenuO ; else {

InteriorMenuAc ion tmenu.nuπiner.≤M[curMsel1 ) ; if (DoNotExitlnteriorj Autαlnt ooόi ; } oldcurP.X— 1; curMsei= -2; } ) else { switch(CADstatus) ( case 1: if (newActive>o&finewActιve!=curActive) { if (0i=GetT_isamIcurActive) ) err(ERR_XINT,50) ^; DrawT_isamfθN) ; SetDownCluCADQ ; upCAD= 0; if (OI=GetT_isaminewActive) ) errfERR_XINT.Ξl) ; if (0!"Getl em(newActive) ) err(ERR_XINT,52) ; curEframe- T _^ isa .destEframe; NextMenu= T_ϊsam. ctmenu; ZeroZeroVart, ) ;

Reaitorelvar() ; . .. _n - «

Appendix Page C-9

SetBelowVarO ; SetSusDVar( l) ; SetFreeVar ( ) ; initlitemO ; AutoInt oo ( ) ;

} brea ; case 2: case 3: if (newActive>0)

{

SetDownCluCAD() ; upCAD= 0;

InteriorMeniiAction(menu.number,-l*CADstatus) if (DoNotExitlnterior) AutoIntLoo () ;

} break; }

if (EqualPt(&curP,&oldcurP)--False)

DupP (ScurP,&αldcurP) ; UpdateUpCAD(curc) ; if (upCAD) MovelnUpCAD() ; else cure- MovelnMenu() ;

} ClearcadPort() ; KillPHfraoeO ; CloseProjDef() ; CloseProjCI()• '

void AutoIntLoop() {

COUNT didF5; LoadMenu(NextMenu) ; while (DoNotExitInterior&&AutoSelect>-l)

{

InteriorMeniiAction(menu.number,AutoSelect) ; if (DoNotExitlnterior) LoadMenu(NextMenu) ; } if (DoNotExitlnterior) DisMenu(); while(DoNot£xitInterior&&CADstatus>3) { if (Xlvar[xlXELΕ7AT]-»0) {

DoF5(); didF5- l;

) else didF5= 0;

Aθvarι;xθAINTGER]= GetInteriorDig() ; InteriorMeniiAction(menu.number,-1) ; if (DoNotExitlnterior) LoadMenu(NextMenu) ; while (DoNotExitInterior&&AutoSelect>-l)

{

InteriorMeniiAction(menu.number,AutoSelect) ; if (DoNotExitlnterior) LoadMenu(NextMenu) ;

) if (DoNotExitlnterior) DisMenu() ; if (didF5) doF5(); . .. _

Appendix Page C-10

id IπtenorMenuActicn (COUNT Mπum . COUNT Msel )

NoChecκ= l ; -f (Msei==-2 )

.WextMenu- SI (-1. 0 ) ; A0var( x0ADGQUADl = πewActive : else if (Msei—3 ) i

if (curP.Y<T_isaa.σR.Ymin) Ca- 0; else if (curP.Y>T_isam.σR.Yaax) Ca= T_isam.gW; else Ca» (curP.Y-T_isam.gR.Yain)/CperI; if (T_isam.retZ—2700) Ca* T_isam.gW-ca; ) AOvar.x0AINTG£R]« Ca; ) else

{

NextMenu- SI(Msel,0) ; switch(Mnua)

{ case El H_INT_COM: switcE(Msel)

{ case 0: if (0.-GetT_isam<ordItem> ) err(ERR_XINT,77) ; if (0!=GetI emιordItemι ) err(ERR_XINT,73) ; curEframe- T isam.destEframe;

NextMenu- T_Xsam.actmenu;

Restorelvar() ;

SetBelowvar() ;

SetSusDVar(l) ;

SetFreeVar() ; initlitemo ; break; case :

DeletelntltemO ; break; case 4:

DeleteIntWindow() ; brea ; ) break; default: if ( (Mnum>18000&&Mnum<19001) I [ (Mnum>28000&&Mnum<29001) ) { litest.subopt[curθptj= Msel; else if ((Mnum>15000&-iMnum<17001) | | (Mnum>25000&&Mnum<27001) )

Appendix Page C-ll

{ curθpt++;

LastODtSel= Msel;

Iitea.opt[curθpt]- Msel; if (Debug«=2) OutOotNeed() ;

) brea ; } if (NoCheckfi&DoNotExitlnterior) CheckSelectAct(Msel) ; }

void InteriorMenuEntryAct() (

CADstatus- menu.Uflag[2] ; switch(CADstatus) ( case 1: newActive" 0; curActive- ordltem; break; case 2: case 3:

SetUpCADQuadrants() ; brea ; ) if (menu.Uflag[3]»4_.l) curEframe-

Appendix Page C-12

XKENU.C

Funticn for leading a new menu

-Old LαadMenurCOUNT numi

:SUNT La; :nsισned cnar caioff; if (__num==EI_M_TILE) caioff= XlvarfxlXCDIOFF. ; f (Onflv=»o, initVart); XlvarfxlXCDIOFF]= cάioff; _.f (HaveODβned)

{ if (Onfly—O) Closeltemf); else if (Onfly=»_.) Closeo Item(;

)

^ιrch(Lnum)

,0) break; ,i) break;

default: mitmenu() ; cpybuf(targ,&Lnua.2) ; if (0!=GT__3S_EC(MENUNUM.TFBMKEY(HENUNDM.targ) ,&menu) ) err(ERR_XMENU,7) if (menu.nua_neri=I_numι err(ERR_XMENU,8) ; if (0i=REDVREC(MENUDAT,£menu,MENUVAR+MENUBASE EN) ) err(ERR XMENU _f 9) ; curMpage- 0; srrcpy(s,-.menu.varf 0]) ;

ToQtxt(s) ; for (La*0; __a<MAXSE ; La++) SelByte Lal= 0; cpybu fSelByre,&meπu. arfmenu.SeiBytel , ^' 2*menu.num≤el) ; if (WhereAmI!=IS_LO0X) { for (La=0; La<menu.nuaSel; La++) Mcof l= -1; if (DoDeltaMco) for (La»0; La<curOeltaMco; La-t→) if (del aMco La] [0l»»»__num>

Mcof (deltaMcofLa] [1]) ]» coMusedF; switch(WhereAmX)

I case IS_TILE: TlleMenu£ntrvAct() ; break; case IS_DEFAϋLT; DefMenuEntryλctO ; break; case IS~CLUSTER: ClusterMenuEntryAc () ; break; case IΞ_INTERIOR: InteriorMenuEntryAct() break; case IS_S?ACEPLAN: SpaceMenuEntryActO ; break;

) DoMenuDMvar() ; DoMenuIF_DMvar() ; AutoSelecε= DoMenuCDK) if (AutoSelecr——•_.) Auroselecr= DoMenuIFsel() •if (AutoSelect:-—!! Debuσ=»l)

{ DoMenuIFnot()

Appendix Page C-13

mo

numMpage- numPhysSel/19; if (humPhysSel-(19*numMDage)>0) numMpage++; if (numMDage==θ) numMoage- l;

)

} brea ;

Appendix Page C-14

XMENUACT.

•" ^x Funtions for aenu entry actions void DoDMvarO

COUNT DMa; for (DMa=o; DMa<menu.numDMvar; DMa++)

( cpybuf(SDMvar.&menu.varfmenu.DMvarByte+(6*DMa) ] ,6)

DoDMvar() ;

C eckActιonVar() ;

}

void DoMenuIF_DMvar ( ) {

COUNT DMa; for (DMa«0 ; DMa<menu.numIF_DMvar; DMa++)

{ cnybuf(&IF_DMvar,&menu.varfmenu.IF_DMvarSv e+(10*DMa) ] ,10) ;

DoIF_DMvar() ;

Chec-CAcεionVar() ;

)

COUNT DoMenuIFsel() { COUNT DMa, DMb,

DMreturn, curByte;

DMreturn- -I; curSyte* menu.IFselByte; for (DMa«0; DMa<menu ^" .numlFsel; DMa++)

{ cpybuf(SIFcon,&menu.varfcurByte] ,6) ; curByte-t— 6; for (DMb«o; DMb<lFcαn.nύaciιeck; DMb-M-)

{ initIFcon_in() ; cpybuf(&IFcon__ιn,&aenu.varfcurBvtel , 6) ; curByte-t— 6;

IFcon. ype(DMb]= lFcon_in.type;

IFcon.nuafDMb1= IFcon_ιn.num;

IFcon.to_typefDMb1= IFcon_m.to_type;

IFcon.to_nuafDM 1= IFcon_in.to_num;

IFcon.comparefDMb]= IFcon_in.comoare; ) if (DoIFconO)

{

DMreturn- IFcon.result; DMb= 30000; DMa* 30000; ) ) return(DMreturn) ;

void DoMenuIFnot()

{

COUNT DMa, DMb, DMc; if (Debugi=l)

^{ Appendix Page C-15

for (DMa-O ; DMa<menu . numSel ; DMa++)

( if (SU(DMa,l)>0)

(

SetMselAct(SU(DMa,l)-l) ; for (DMb=0; DMb<MselAct.numIFnot; DMb++)

(

IFcon= MselAct.A_IFno rDM ] ; if (DoIFconO) SM[DMa1= 0;

) DMb= 0; DMc- 0; numPhysSel= 0; for (DMa=θ; DMa<menu.numSel; DMa++) { if (SM[DMa]) {

SMTDMcl- DMb; DMc++; DMb++; numPhysSel++;

) else DMb++;

void DoDMvar() { unsigned char to_val; switch(DMvar.to_type) to val- DMvar.to_num; break; to~val« ACTvar[DMvar.to nu ] ; break; to~val= CLOSEvar[DMvar.to num] ; brea ; to~val= QCLOSEvar[DMvar.to_nu ] ; break; to_val= DEFvar(DMvar.to_num] ; break; to_val= covar[DMvar.to_num] ; break; to_val= civar(DMvar.to_nuaj ; break; to_val= I0varfDMvar.to_num] ; break; to~val= IIvarfDMvar.to num] ; break; to_val= Tθvar[DMvar.to~numj ; break; to val- TlvarCDMvar.to~numj ; break; to~val= AθvarfDMvar.to_numj ; break; to_val= Alvar[DMvar.to_num] ; break; to_val» XOvar[DMvar.to~numj ; brea ; to~val= Xlvar DMvar.to_num] ; break; to_val= _8var[DMvar.to_num] ; brea ; to~val= _4var[DMvar.to ^" ~num] ; break; to~val= _2var[DMvar.to_numj ; break; err(ERR XMENUACT,206) ;. break; switch(DMvar.change)

( case 0: switch(DMvar.type)

( case 1: ACTvar[DMvar.num]= to val; break; case 2: CLOSEvar[DMvar.num]= to~val; break; case 3: QCLOSEvar[DMvar.num]= to_val; break; case 4: DEFvar[DMvar.num]= to val; break;

Appendix Page C-16

ro_val; oreak; to_val; break; to_val; creak; to_val; break; to_val; creak; to_val; break; to val; break: to_val; break; to_vai: break; to_val; break; to_val; break; to_val; break; to val; oreak; 05) ; break; orea ; case 1: switc (DMvar. vpe)

( case 1: ACTvar[DMvar.num1+ ^« to_val brea ; case 2: CLOSEvarfDMvar.nύm]+« ^■ to_val break; case 3: QCLOSEvarfDMvar.num]+■ to_val break; case 4: DEFvarfDMvar.num]+« to_val break; case 5: C0var[DMvar.num1+« to_vai break; case 6 : ClvarfDMvar. umj+« to_val break; case 7: 10varfDMvar.numj+ ^« to_val breatc; case 8: 1 arfDMvar.numj+« to_val breatc; case 9: TOvarfDMvar.numj+■ to_val break; case 10: TlvarfDMvar.numj+• to_val break; case ii: AOvar[DMvar.num]+ ^« to_val break; case 12: AlvarfDMvar.nua)+■ to_val break; case 12: XOvar[DMvar.nuaj+- to_val break; case 14: XlvarfDMvar.nua]+- to_val brea ; case 15: _8varfDMvar.numj-t— to_val break; case 16: _4varfDMvar.num»+• to_val break; case 17: 2varfDMvar.nuai+- to val break; default: err(ERR XMENUACT,204) ; brea ; break; case 2: switc (DMvar. ype)

( case 1; ACTvarfDMvar.num]-« to_val break; case 2: CLOSEvarfDMvar. ύm)— to_vai crea : case 3: QCLOSEvarfDMvar.nua1— to_val orea ; case 4: DEFvarfDMvar.nua]—« to_vai breax; case 5: COvarfDMvar.nua}— to_val break; case 6: ClvarfDMvar.nt_mj— tojval break; case 7: IOvarfDMvar.nuaj-• to_vai break; case 8 IlvarfDMvar.nua]— to_val break; case 9 TOvarfDMvar.nua)— to_val break; case 10: TlvarfDMvar.nuaj— to_val break; case 11: AOvarfDMvar.num]— to_val break; case 12: AlvarfDMvar.num)— to_val break; case 12: XOvarfDMvar.nua]— to_val break; case 14: XlvarfDMvar.nuaj— to~val break: case 15: _8varfDMvar.nual— to_val break; case 16: _4varfDMvar.nuaj-« to~val break; case 17: _2varfDMvar.nu I— to val oreaκ; default: err(ERR XMENUACT,203) ; breax;

) break; case 3: switch(DMvar.type) { case 1: ACTvar[DMvar.num]*> to' val ; reaic:

Appendix Page C-17

case CLOSEvarfDMvar.num1*= to_va±; break; case QCLOSEvarfDMvar.numj*= tojval; break; case 4: DEFvarfDMvar.num)*= tojval; break; case 5: COvarfDMvar.num1*= tojvai; break; case 6: ClvarfDMvar.nuaj*= to_val; break; case 7: IOvarfDMvar.nuaj*= tojval; break; case 8: IlvarfDMvar.nua1*= tojval; break; case S: TOvarfDMvar.nuaj*= tojval; break; case 10: TlvarfDMvar.numj*= tojval; break; case 11: AOvarfDMvar.num1*= to_val; break; case 12: AlvarfDMvar.nuaj*= tojval; break; case 13: XOvarfDMvar.num ) *- to_val; break; case 14: XlvarfDMvar.numj*= to_val; break; case 15: _8var(DMvar.num}*= to val; break; case 16: 4varfDMvar.num1*= tojval; break; case 17: ~2varfDMvar.num.*= to~val; break; default: err(ERR XMENUACT,202) break; break; case 4: switch(DMvar.type) case 1: ACTvar(DMvar.num]/= tojval break; case 2 : CLOSEvarfDMvar.nύm]/= to val break; case 2 : QCLOSEvar(DMvar.nua]/= to_val break; case ; DEFvar[DMvar.num]/= to~val break; case 5: COvarfDMvar.num)/= tojval break; case 6: ClvarfDMvar.num]/= tojval break; case 7; IOva (DMvar.numj/= tojval break; case 8: IlvarfDMvar.numj/= tojval break; case S: TOvar[DMvar.num]/= to val break; case 10: TlvarfDMvar.num]/= to~val break; case 11: AOvar[DMvar.nua]/= tojval break; case 12: Alvar[DMvar.nua)/= to_val break; case 13: XOvarfDMvar.num]/= to_val break; case 14: XlvarfDMvar.num] « to_val break; case 15: _8varfDMvar.num] = tojval break; case 16: 4varfDMvar.nua]/= to val break; case 17; ~2varfDMvar.num1/« to~val break; default: err(ERR XMENUACT,201) ; break; ) break; default: err(ERR_XMENUACT,208); breax;

}

void DoIF DMvar() {

COUNT Da; unsigned char comp val, val;~

Da» 0; switch(IF DMvar.comp_type) com _val« IF_DMvar.comp_num; brea com ^" val" ACTvar[IF_DMvar.comp_num] ; brea comp ^" val= CLOSEvar(IF_DMvar.cόmp_nύ ] ; brea comp ^{' "} val« QCLOSEvar[IF_DMvar.comp_num] ; brea comp ^{' "} val= DEFvarfIF_DMvar.comp_n m] ; brea como _val= COvarfIF_DMvar.comp_num] ; brea cαmp_ ^" val _* ClvarfIF_DMvar.comp_num] ; break comp ^"" val= IOvarfIF_DMvar.comp_num] ; breax

Appendix Page C-18

case 8 : : creax; case 9: ; breax; case 10 ; areax: case 11 ; breax; case 12 ; breax: case 12 ; breax; case 14 ; breax; case 15 ; breax; case 1= ; breax; case IT ; breax; default breax; switch ,' IF_DMvar. type ) case 1: val- ACTvarfIF_DMvar.num} ; break; case 2: val*= CLOSEvar[IF_DMvar.nύm1 ; break; case 3: val- QCLOSEvar IF_DMvar.πumJ break; case 4 : val- DEFvarfIF_DMvar.nua1 ; break; case 5: val- COvarfiF_DMvar.numl ; break; case 6: val» ClvarfIF_DMvar.numj; break; case : val- IOvarfIF_DMvar.num] ; break; case 8: val- IlvarfIF_DMvar.num] ; break; case 9: ale TOvar[IF_DMvar.numj ; break; case 1C val- TlvarfIF_DMvar.num1 ; brea ; case 11: val- AOvarfIF_DMvar. umj ; break; case 12: val» Alvar(IF_DMvar.numj ; breax; case 12: val= XOvarfIF_DMvar.numj ; breax; case 14: val- Xlvar(IF_DMvar.numj; breax; case 15: val- _8varfIF_DMvar.nua) ; break; case 15: val= ~4varfIF_DMvar.nuaj ; break; case 17: val- _2varfIF_DMvar.numj ; break; default: err(ERR XMENUACT,212) ; break; ) switch(IF_DMvar.compare)

( case 0: if (val—compjval) Da- 1; break; case 1: if (vali-compjval) Da- 1; break; case 2: if (val< compjval) Da- 1; break; case ₃ . if (val> compjval) Da« l; break; case 4 : if (val<=ccmpjval) Da- 1; break; case 5: if (val>-cαmt._vali Da- 1 • break; defaul : err(ERR_XMENUACT,215) ; breax; i f (Da) (

DMvar.cnaπσe- IF_DMvar.cΛange; DMvar.type- IF_DMvar.aαdjtype; DMvar.num- IF_DMvar.aod_nua: DMvar. o_type« IF_DMvar.tojtype: DMvar. o_num« IF DMvar. o nua; DoDMvarO ; )

COUNT DoIFconO { COUNT DIa,

DIreturn; unsigned char to val, val;

DIa- 0; DIreturn- 1; switcn(IFcon.howcneck) {

Appendix Page C-19

case 0: while (DIreturn&&DIa<IFcon.numcheck) i switch(IFcon. o_type[DIa] )

( case 0: to_val= IFcon.tojnumfDIa]; brea case 1: to_val= ACTvarfIFcon.to _nua[DIa] ] ; brea case 2 : to_val= CLOSEvar[IFcon to_nύa[DIa] ] ; brea case : to_val= QCLOSEvarfIFcon to_num[DIa] ] brea case 4 : to_val= DEFvar[IFcon.to numfDIa ]; brea case 5: to_val= COvar[IFcon.to num[DIa] brea case 6: to_val= Clvar(IFcon.to_:numfDIa] brea case 7: to_val= IOvarfIFcon.to_:numfDIa] brea case 8: tojval- IlvarfIFcon. o numfDIa] brea case 9: tojval- TOvarfIFcon.to ^' numfDIa] brea case 10: tojval- TlvarfIFcon.to_:numfDIa] brea case 11: tojval- AOvar[IFcon.to_:numfDIa] brea case 12: to~val= Alvar[IFcon.to ^" numf Ia] brea case 13: to_val= XOvarfIFcon.to_:nua[DIa] brea case 14: to_val= Xlvar[IFcon.to_:nua[DIa] brea case 15: tojval- _8var[IFcon.to nu [DIa] brea case 16: to_val= _4var[IFcon.to ^' nua[DIa] brea case 17: to_val= _2varfIFcon.to ^' nua[DIa] brea default: err(ERR_XMENUACT,217); ^' brea switch(IFcon.type[DIa])

{ case 1: val- ACTvar[IFcon.nua[DIa] ] ; break; case 2: val- CLOSEvar[IFcon.nύafDΪa] ] break; case 3: val- QCLOSEvar[IFcon.nua[DIa] ]; break; case 4: val- DEFvar[IFcon.nua[DIa ] break; case 5: val- COvar[IFcon.nua[DIa] break; case 6: val- Clvar[IFcon.nua[DIa] break; case 7: val- IOvar[IFcon.nua[DIa] break; case 8: val- Ilvar[IFcon.nua[DI ] break; case 9: val- TOvarfIFcon.numfDIa] break; case 10: val- Tlvar(IFcon.numfDIa] break; case 11: val- AOvar IFcon.numf Ia] break; case 12: val- AlvarfIFcon.nuafDIa] break; case 13: val- XOvarfIFcon.nu [DIa] break; case 14: val- Xlvar[IFcon.num[DIa] brea ; case 15: val- _8varfIFcon.nua[DIa] break; case 16: val- _4varfIFcon.num[DI ] break; case 17: val- ~2varfIFcon.nuafDIa] break; default: err(ERR_XMENUACT,218) break; ) switch(IFcon.coapare[DIa])

{ case 0: if (val!-to val) DIreturn- break; case 1: if (val=»to~val) DIreturn- break; case 2: if (val>=tojval) DIreturn- break; case 3: if (val<-to_val) Dlreturn- break; case 4: if (val> to_val) Dlreturn- break; case 5: if (val< to_val) DIreturn- break; default: err(ERR_XMENUACT,220) break;

} DIa++;

) break; default: err(ERR_XMENUACT,216); break; ) return(DIreturn) }

Appendix Page C-20

^' * XMSELACT.C

*/ '* Funtions fcr rsenu selection actions */

void DoActDMvarO {

COUNT DMa; for (DMa=0; DMa<MselAct.numDMvar; DMa+f)

{

DMvar- MselAct.AJDMvarfDMa1 ;

DoDMvar() ;

CheckActionVar() ;

)

void DoActIF DMvar() {

COUNT DM ; for (DMa«0; DMa<MselAct.numIF_DMvar; DMa++)

IF_DMvar= MselAct.A_IF_DMvarfDMa] ; DoIF DMvar() ; ChecicActionVarO ; } )

void DoActDMvar2() {

COUNT DMa; for (DMa-O; DMa<MselAct.numDMvar2; DMa++)

{

DMvar- MselAct.A_DMvar2[DMa] ; DoDMvar() ; CheckActionVar() ; ) )

void DoActIF_DMvar2() {

COUNT DMa: fcr (DMa=o; DMa<MselAct.numIF_DMvar2; DMa-t-f)

(

IF_DMvar= MselAct.A_IF_DMvar2[DMa] ;

DoIF DMvar ( ) ;

ChecϊϊActionVar ( ) ;

void DoActlFpart() (

COUNT DMa, DMb; for (DMa-O; DMa<MselAct.nualFpart; DMa+f)

{

IFcon- MselAct.A_IFpartfDMa] ; if (DoIFconO)

{ if (IFpartNoACTout—1) err(ERR_XMSELACT,1111) ;

IFpartNoACTout- l;

T_added« o ; initT isam() ; switcH(WhereAml) Appendix Page C-21

case IS_INTERIOR: DoIFpartlnterior f ) break ; curOot- -I ; DMa= ^* 30000 ;

void DoiFpartlnterior O

{ litem.number- curltem; Iitea.orddes- ordltem; litem.Uvarfl lAss+xlACONCUR.= AlvarrxlACONCURI Iitem.Uvar[I~lAss+xlACONDESϊ= AlvarfX1ACONDES] ^' Iitea.Uvar[I~0Ass+xOATRANS 1= AOvarfXOATRANSX] Iite .Uvar[I~0Ass+xOATRANSY]= AOvarfXOATRANSY] litem.Uvar[I OAss+xOATRANSZ]= AOvarfXOATRANSZ] Iitem.Uvar[I~0Ass+xOANODRAW]= AOvar(XOANODRAH] Iitem.Uvar[I_0Ass+xOALTGEO]= AOvarfxOALTGEO] ; if (litem.number>l)

{ litem.deletable- 1;

T isam.deletable- 1;

Iitem.Manu_Line[0]= Manu_Linef0] ; Iitem.Manu_Line[1]= Manu_Linef1] ; strcpy(litem.part,&MselAct.A_part IFcon.result] [0])

_ιsam.number- curltem; T_isam.orddes- ordltem; T_isam.concur- Alvar[ lACONCUR] T_isam.condes- Alvar xlACONDES] T_isam.nodraw- AOvar[xOANODRAW] T_isam.altgeo- AOvarfxOALTGEO] ; T~isam.heightf3] AOvar[XOATRANSY] IntPhysicalln(NEW) ; curltem++; ) void DoActlFgoto() { COUNT DMa; for (DMa-O; DMa<MselAct.nuaIFgoto; DMa++) (

IFcon- MselAct.A IFgoto[DMa] ; if (DoIFconO) ~

(

NextMenu- IFcon.result;

DMa- 3000;

void CheckSelectAct(COUNT Msel) { if (SU(Msel,l)>0) {

SetMselAct(SU(Msel,l)-l) ; DoActDMvar() ; DoActIF DMvar() ; DoActlFpart() ; DoActDMvar2() ; Appendix Page C-22

DoActIF_DMvar2 ( ) DoActlFσoto ( ) ;

Appendix Page C-23

ir.tions Dβrtaming to items

,-oιd Add!tearCOUNT hatln) partNoACTout-»0) err(ERR_XITEM,7777)

_rpar ..'oACTout- 0; switcr. '.WhereAal)

fcr (Aa»0; Aa<£I_sXSI; Aaι-ι-t άest8IΑa.= lire .Uvarf I_3ss+f 9*Aa) ] fcr ;λa=0r Aa<EI_sX4I; Aam άest4fAai= litem. Uvarf I_4ss+( 5*Aa) ] cr .'Aa-0? Aa<£I_sX2I; Aa+-) desc2fAaj= litem. Uvarf I_2ss+f 3*Aa) j _f .c rccπαes<9) fcr (Aa«0: Aa<EI_sX8I: Aa++>

Zitem.Uvarf I_3ss+(9*Aa)-ccur==r.des]= c rδfAa] ;

_-f (curcondes<5) fcr (Aa-0; Aa<EI_sX4I; Aa++. litem. Uvar fl_4ss+f 5 *Aa)+cur==r_desl = cur4fAa] ; i f ( curcondes < 3 )

i ^b

id Ir.tPhysιcalIn(COUNT NewOld)

* Physical insertion of an interior item: called from IFpart true in

* XMSE ACT.C and when loading an old interior database. ^" ir.vertCld= 0 ;

if (Newθld»»NEW)

{ if (T_isam.type—ACTIVE)

{ invertoid- ordltem; invertNew- litem.number;

□rdltem= Iitem.number;

) ) if (T_iscm.nodraw»«4»04ST_isam.useGeof0] !='\0'*& strncmp("222",T isam.useGeo,3) !=0) { if (0!»GetGeo(T isam.useGeo) ) err(ERR_XITEM,81) ; if (fabs(geo.vector[0] .Xl-geo.vectorι_0].X2)<.005)

{ if (geo.vectorr0] .Yl>geo.vector[0] .Y2) BaseDirConl= 2700; else BaseDirCoήl= 900;

) else

( if (geo.vectorro].Xl>geo.vector[0].X2) BaseDirConl= 1800; else BaseDirCoήl= 0;

) nsx« geo.veetorflitem.ϋvar[I lAss+xlACONCUR]-l].Xl- item.Uvar(I_0Ass+xOA nsy» geo.vector[lite .Uvar[I~lAss+xlACONCU ]-1] .Yl-Iitem.Uvar[I_0Ass+xOA nfx» geo.vector(litem.Uvar[I_lAss+xlACONCUR]-l] .X2-Iitem.UvarfI OAss+xOA πfy= geo.vectorrlitem.Uvar[I_lAss+xlAC0NCUR]-l] . 2-Iitem.UvarfI~θAss+xθA nz= geo.vector(Iitem.Uvarfl_lAss+xlACONCUR]-l] .Z- litem.UvarfI_0Ass+x0A if (Iιtem.number>LeastItem) ~ ~

{ if (0 ! =SaveT isam (NEW) ) err(ERR_XITEM _f 82 ) ; if ( 0 ! =GetT_Tsam ( litem. orddes ) ) err (ERR_XITEM, 83 ) ;

Appendix Page C-26

=ri£frame- T_isa .αestEframe; i f01=GetGeα(T_ sam.useGeoi ) err(ERR_XITEM.84. ; fioatnoι.X= σeo.vecto flitem.UvarfI_lAss+xlACO_.DES.-i..XI; fioat oι.ϊ= eo.vectorflitem.Uvar.^I_lλss+xlACO_ϊDESi-II .Yl; rstfloatDOifT_isam.rotZ. ; asx= fIaatpαι.X÷T_isam.lαcX; asy= fioatooι.ϊ ^" ÷T_isam.iocϊ; flάatpoι.X= geo.vectorflitem.UvarfI_lAss+xlAC0NDES1-i ..X2; fioatpoι.ϊ= geo. ectorflitem.UvarfI_IAss+xlACO:.DESj-i, .ϊ2; rs i a polfT_is m.rctZi ; afx= fIoatpoι.X÷T_isam.locX; afγ= floatpoi.Y÷T_isam.iocb_; az= σeo.vectorf item.UvarfI_lAss+xlACO_.DES1-11.Z+T_isam.lccZ; if (01=GetT_isam(litem.numner) ) err(ERR_XITEM.85) ; if (T_isam.dest£frame«»θ) T_isam.destEframe« ordEframe;

if (Nevθld-*NEW) { if (invertold>0)

{ if (0!»GetT_isam(invertOld) ) err(ERR_XITEH,90) ;

DrawT isam(UD_0N) ; if (θT-GetT_isam(invertWev) ) err(EKR_XITEM.91) ;

}

Appendix Page C-27

.11Δ-

. invertNew>l) Draw _isam(UD_HIGHL)

Appendix Page C-28

xc runtions fcr r.andling the insertion of an Interior sur>-assetαbly nto a cluster asseπmlv design database.

■Old cadCluMenu_Interιcr(COUNT Nor≤) fcr C a=3001. a<4000; La-t→) if .0=«GetCI'La, 'A'v0) ) curBvte- CheckAddTcInterMenu(curSyte,NorS, 0) ;

! else La= 30000; f (numJ?hysSel«»MAXSEL-2) a= 30000; !

COUNT CheckAddToInterMenu(COUNT curSyte. COUNT NorS, COUNT doall)

I if f 0 ! =GetT_isa__.. ordltem ) ) err ( EER_XC U_T ,200); fxl= T_isa_n.locX; fyl= T_isam. loci. : frctZ= T_isam.rotZ; fii* T_isam.σH; f (HαrS—WAtlSIRΪF)

{ f otz÷- 900; if (frotz>2700) frstz— 3600; switch( rotZ)

{ case 0: fxl— 48; fyl+- 0.25: break; case 900: fyl— 48; fxl— 0.25; break: case 1800: fxl+« 48; fyl— 0.25; break: case 2700: fyl+- 48; fxl+- 0.25; break; default: err(ESR_XCLU T,241) ;

)

) else

{ switchffrotZ)

{ case 0: fx2= fxl+T_isam.σ ; fy2= fyl; break; case 900: fx2= fxl; fy2= fvl+T isam. W; break; case 1S00: fx2= fxl-T_isam.σW; ry2= fyl; break; case 2700: fx2= fxl; fy2= fyl-T_isam.gW; break; default: err {ERR_XC U_T,201);

)

) for (Ca«θ; Ca<5; Ca++) T_IarrfCa]«= 0; for (Ca»0; Ca<10; Ca+i*) T_Uarrι;ca]= 0; ret** curSyte: islegal= 0; for (Ca»l: Ca<«CIbase.nu_ncipoi; Ca=-+)

{ if (0!=GetCIfCIbase.CInum.CIbase.rev,Ca) ) err(EKR_XC U_T,223) ; coybuf,£PHframe.usedr (Ca-l)/7] [11* ( Ca-l-(7* ( (Ca-l)/7) ) ) ] ,&CIpoι.z.ll) ;

) ^" for (Ca-1; Ca<«CIbase.nu__tCIpoi; Ca++) ctsybuf (£CIpoi.z,£PH rame.usedr (Ca-l)/7] [11*( Ca-l-(7*( (Ca-l)/7) ) ) ] ,11) ; if (CIpoι.z<«fh)

{ Appendix Page C-29

-11..-

Ix= CI oi.xl;

"I = CIsox.vl; f ,'MorS—SOUTH! INorS∞ A.LLSTI.1?) cr=tZ= CIsci. ir. dir-frczz+θOO ; else crctz= cipαι.ir.tdιr-frsrz-900; f fcrstZ-cO) crctZ+= 3600; else if fcrotZ>=3600) crotZ-= 3600; fioatpcι.X= fxl; ficatccι.Y= fyl; rctflcatpoKcrctZ. ; caoveX= Clx-floarpoi.X; cπoveϊ= Cly-floarpoi.Y; if fdόall)

else < if (l ^β -DoeslnterFitCIuster(caoveX,caoveϊ,crotZ) )

{

Ca- 30000;

if ( l=-DoesInterFitCluster<caoveX, caoveϊ . crorZ ) ) ca= 30000;

Appendix Page C-30

f .Ca==30001)

SelByternum_._ιysSell= ret: cpycu f&menu.varfre ] ,T_Iarr.10) ; ret+= 10; cpyDur &menu.varfrsti ,τ_Uarr.lθ) ; rer-t— 10; sόrir. ffs, "%3d%c ^" %s" ,CI_3ase.CIr.un-3000.CI-_ase.rev,Clbase.namei ; if (s.oi—' ') s(01= '0'; f .sfll==' ') sflj= '0'; sfl5}= '\0': cpyD f&menu.varfrer] ,s,15) ; ret+= 20;

__u_i-PhvsSel++• j return.ret) ;

)

COUNT __oeslnterFitCiuster(float craoveX, float cr_ove¥, COUNT cratZ)

COUNT Ca, C , a teb, ret: f ) ;

i e return(ret) ; }

COUNT T_isamCIooιFit( loat caoveX, float caoveϊ, COUNT crotZ) { COUNT ret, f ot2. rot2; float fxl. fX2, fyi. fy2; ,

Appendix Page C-31

. et= 0 ;

Lf fCI?oi.z<=T_isam.gH) floatpoi. x= T_isam.locX;

fyl)<FTOL) ret= 1;

yl; break; gW; break; yl; break; gW; break; brea ; l-fy2)<FT0L) ret= 1; r }

void CluMenu InteriorAction ( COUNT Snum, COUNT Mnum) {

COUNT Ca ; if (Snum<numPhysSel-l)

{ initCitem ( ) ;

Ca= atoi(&menu.var[34+(40*Snum)+20] )+3000; sprint (s,"I*4d%c",Ca,menu.var[34+(40*Snum)+23]) ; strcpy(SCitem.part[1] ,s) ;

Citem.part[0]= '%';

T_added= 0;

IFpartNoACTout= 1; initT_isam ( ) ;

T_isam.DBAin= Ca;

T isam.DBAinrev _* menu. varf 34+(40*Snum)+23] ;

T~isa . type= TYPE_INTERIOR ;

T_isam. graphic* GRAPHIC_INTERIOR; if (Mnum«— 2) SetT_isamlnteriorlnfo (Ca, NORTH) ; else if (Mnu_n»»-3 ) SetT isamlnteriorlnfofCa, SOUTH) else SetT isamInteriorInfo(Ca,WALLSTRIP) ;

DoIFpartcIustet (INTERIOR) ; curθot= -1;

Addltem(INTERIOR) ;

^} Appendix Page C-32

void SetT_isamIntencrInfo( COUNT Inum. COUNT NorS) .

COUNT Sa, Sb. Sc, rz , rz2; struct T_isam_σs ΞT_isam; cnar ^" ch ; float lx, ly, 1x2, ly2; coybuf I £ST_isam , &T_isam . _ISAMRECLΞ ) ; if (0!=GetCIfInum, 'A' ,0) ) err(ERR_XCLU_T, 206) ; numPhysSel= 0;

ChecxAddToInterMenu ( 100 , NorS , 1 ) ; coybuf f ST_isam . &ST_isam . T_ISAMRECLEN) ; if (nu___PhysSel-«0) err(ERR_XCLU_T,208) ; for (Sa=θ; Sa<numPhyssel; Sa++)

( cpybuff&lx,&SSet.var[Sa*lO],4) ; cpybuf(£ly,&SSet.varf (Sa*10)+4] ,4) ; cpybuf f&rz,&SSet. varf (Sa*10)+8] ,2) ; for (Sb»Sa+l; Sb<numPhysSel ; Sb++)

{ cpybuf(£1x2,&SSet.varfSb*101 ,4) ; cpynuf(Σtlv2,&SSet.var( (Sb*10)+ 1 ,4) ; coybuf (&rz2.&SSet. varf. (Sb*10)+8. ,2) ; if ( f abs ( lx-lx2 ) <FTOL&&f abs ( ly-iy2 ) <FT0L&&rz=»rz2 )

{ for (Sc«Sb; Sc<numPhysSel-l; Sc++)

{ cpybuff&SSet.var[Sc*10] ,&SSet.var[ (Sc+1) *10] ,4) ; cpybufr&SSet.var[ (Sc*10)+41 ,&SSet.varf ( (Sc+1) *10)+41 ,4) ; cpybuf(&SSet.vart(Sc*10)+8],&SSet.var( ( (Sc+1) *10)+8] ,2) ; ) πumPhysSel—-;

) ) )

Sa» 0; if (numPhysSel= _* l)

{

TemoOrawT_isamInterior(S ,UDADD_ON) ; ! else

{

GetPenState(&pState) ;

ProtectRect(&mR) ;

BackColor(CoMqueB) ;

PenColor(CoMσueF) ;

MoveTo(5,mtextY*(2) ) ;

Drawstring("<SPACE> to cycle thru Iocs") ;

MoveTo(5,mtextY*(3) ) ;

Drawstrin ("<RETURN> to acceot") ;

ProtectOff() ;

SetPenState(&pState) ; ch* 0;

TemDDrawT_isamInterior(Sa,UDADD_ON) ; while (ch! =13)

{ ch- σetch() ; if (cn«-32)

{

TempDrawτ_isamInterior.Sa.UD_θFF) ; if (Sa<numPhysSel-l) Sa+-t-; else ≤a« o ;

Appendix Page C-33

TemDDrawT_isamInteπor(Sa,UDADD_ON) ) cpybuf ( SCitem. GtileN TO], &T_isam. locX , ) cpybuf . SCitem. GtileNf ] , &T_isam. locϊ , 4 ) spyouf (&Citem.Gtilesf 3] , &T isam.rotZ,2)

}

void TempDrawT_isamInterior(COUNT num, COUNT mode) cpybuf(&T_isam.locX,&SSet.varfnum*10] ,4) ; cpybuff&T isam.locY,&SSet.var[ (num*10)+4] ,4) ; cpybuff&T ^"" isam.rotZ,SSSet.var[ (num*10)+8] ,2) ; DrawT_isaϊ(mode) ;

Appendix Page C-34

_• » r .-.r cns for manipulating and using PHframe records m resDonse -c non-zero action variables.

^• oid DcActKigήO

_. • * This functions is called from XHENU.C vhen ACTvarf ACTHIGKj>0 in order -* ro cause the variables 1XVEK.T01-1XVER.T30 to be set fcr menu logic, for ,->a=0; _>a<30 Da-t→) πaxVrDa.= 0; defVfDai= 0;

else maxvri5] maxV.16] . maxV 17} maxVf18} maxV[19] maxV.20} maxvf21] maxV[22] maxvr23] maxV.24} maxv 25] maxv 261 maxV 27] maxVΪ28]

)

Appendix Page C-35

void SetPHacross(COUNT num) if (0!=GetPHframe(num) ) err(ERR_XINT_ACT,25) ; initPHacross() ; UDdatePHacross() ; )

void initPHacross()

(

COUNT la; for (la=0; Ia<86 Ia++) PHacrossfIa]= 127;

) void UpdatePHacross()

{

COUNT Sa, Sb? for (Sa=0; Sa<86 Sa++)

{ if (Sa<PHframe. eight)

{ for (Sb=0; Sb<PHframe. idth; Sb++) if (PHacross(Sa}>PHf ame.used[Sb} [Sa}) PHacross[Sa]= PHframe.use fSb] [Sa] ; } else PHacross[Sa]« 0;

) ) unsigned char maxV_PHacross(unsigned char inval) {

COUNT ma, mb, mc; unsigned char curV, maxV; maxV= 0; curV= o; mb* Xlvar[xlXDITEM} ; for (ma-6; ma<86 ma++)

{ mc= PHacrossfma} ; if (mc>»mb) curV++; else curV= 0; if (curV>maxV) maxV= curV;

> if (XlvarfxlXDIGTYP]=*inval+l) cpybuf(&PHdig[0} ,&PHacross[0] ,86) return(maxV) ;

unsigned char defV PHacrossQ

{

COUNT a, mb, mc; unsigned char defV; defV= 1; mb» Xlvar[xlXDITEM} ; for (ma«ACTvar[xACTHIGH}-l; ma>ACTvar[xACTHIGH}-l-Xlvar[xlXHITEM} ; ma-

{ mc» PHacrossfma] ; if (ma<6| |mc<mb)

{ defV» 0; break; ) ) return(defV) ; _ ,,

Appendix Page C-36

void SetVOf)

SetPHacrcssfPHadi ro .. umoeri aaxvro ^* .= maxV_FHacr=ss(0) ; defVfoi= defV PHacrcss< ) ;

.-old SetVl_6() switch(PHad [0} .width) i case 24: =axvm= maxvroi; defvm= defvroi; if (XlvarfxlXDIGTYP]—2) cpyouf(UPHdigfO] ,&PHacrossf0} ,86 ₎ break;

void Setvs 6() {

COUNT Sa: if (PHadj[0} .width= •24) { for (Sa=l; Sa<numPHad ; ≤a-H-) { if (PHadj[Sal .left==l&&PHadj[Sal .crthoσ=0&& PHadj [Sal.dist_ieft=-24&&PHadj [Sal .width»24)

{

HanσMatch(5 , 0 , Sa .0 , 0 ) ; HangMatch(23 , 2 ,≤a , 0 , 0) ; ) else if (PHadj [Sal . left=2&4PHadj [Sal . orthoσ=»θ&& PHadj [Sa] .dist_ieft=»2 &iPHadj [Sal . wιdth=-24 )

{

Appendix Page C-37

HangMatch ( 6 , 0 , sa , o , 0 ) ; HangMatc (24,l,Sa,o,0) ;

void SetV9_i0_29()

Sb= Sc= Sd= Se- Sf= Sg= S__= Sι= Sj= Sk= Sl= Sa-* 0; fcr fSa=l; Sa<numPHadj ; Saι--ej

if' (Sb>0&&Sc>0)

HanσMatch(9,0,≤b,Sc,0) ;

HangMatc (27,2,Sb,Sc,0) ;

) if (Sd>0££Se>0)

{

HanσMatch(10,0,Sd.Se,0) ;

H.angMatch(28,l,Sd,Se,0) ;

) if (Sb>0&&Sd>0)

{

HangMatch(29,0,Sb,Sd,0) ;

) break; case 48: if (Sb>0)

{

HanσMatch(9,0,≤b,0,0) ;

HangMatch(27,2,Sb,0,0) ;

■appendix Page C-39

if (Sd>0)

(

HanσMatch(10,0,Sd.0,0) ?

HangMatc (28,l _f Sd,0,0) ; i brea case 30: if (Sj>0)

(

HanσMatch(9, 0,Sj ,0,0) ;

HanσMatch(27,2,Sj,0,0) ;

) if (Sk>0) (

HanσMatch(10,0,Sk,0,0) ; HangMatch(28,l,Sk,0,0) ;

) break; case 42: if (Sh>0)

{

HanσMatch(9,0,Sh,0,0) ; HanσMatch(27,2,Sh,0,0) ; ) if (Si>0)

(

HanσMatch(10,0,Si,0,0) ; HanσMatch(28,l,Si,0,0) ;

) break; case 36: if (S1>0)

{

HanσMatch(9,0,Sl,0,0) ; HangMatch(27,2,Sl,0,0) ;

> if (Sm>0)

{

HanσMatch(10,0,Sm,0,0) ; HangMatc (28 _r l,≤m,0,0) ;

) break;

void SetVll_12() (

COUNT Sa? if (PHadj [0].width—30) { for (Sa=l; Sa<numPHadj ; Sa++) { if (PHadj[Sal .left—lfi&PHadj[Sal .orthog==l&&PHadj [Sal .dist left==o&& PHadj [Sa] .width—30&&PHadj[Sa] .dist orthoσ—30) {

HangMatc (11,0,Sa,0,0) ; ) else if (PHadj [Sa] ,left==2&5PHadj [Sal .crthoσ—1&& PHadj [Sa] .dist_left—30&&PHadj [Sal .wιdth==30&& PHad [Sa] .dist_crthoσ=-0)

{

HangMatch(12,0,Sa,0,0) ; )

Appendix Page C-40

void SetV12_14()

COUNT Sa; f .'PHadj f0].width—36) fcr fSa=l; Sa<nu PHad ; Sa++) t if (PHadifSal .left—l&δPHadi [Sal .crthoσ—l& PHadj [Sal .dist_Ieft—Oδδ PHadj[Sa].width—36&δ?Hadj[Saj .dιst_cr hog—36)

HanσMatch (l2,0,Sa,0,0) ;

) else if (PHadj [Sal . left— 2&δPHadi [Sal . orrhoσ— lδδPHadi [Sal .dist left PHadi [Sal .width— 36 δδPHadj [Sal . dist_crrhoσ— 0 )

{

HanσMatch ( 14 , 0 , Sa , 0 , 0 ) ;

)

)

void SetVIS 16 () (

COUNT Sa; if ( PHadj [0]. width— 42) { for (Sa-l; Sa<numPHadj ; Sa-M-) if (PHadj [Sal .left— l&δPHadj [Sal .αrthoσ— lδδPHadj [Sal ,dist_left— Oδδ

PHadj [Sa] .width— 42 δPHadj [Sai .dist όrrhog— 2)

{

HanσMatch (IS, 0,Sa, 0,0) ;

) else if (PHadi[Sal .left—2&δPHadi[Sal .αrrhocr—lδδ

PHadj[Sa] .disr_ieft—42δδ?Hadj [Sal .width—42δδPHadj [Sa] .dist_orthoσ

{

HanσMatch(16,0,Sa,0,0) ;

) )

void SetV17 18()

{

Sb- Sc« Sd- Se- Sf- Sg= Sh- Si- 0; for (Sa-i; Sa<nu___PHadj ; Sa++) { if (PHadi[Sa].left—lδδPHadj[Sal.orthoσ—l δPHadj[Sal .dist_left—Oδδ

PHadj[Sal. idth—48δδPHadj[Sai.dist όrthoσ—48) Sf- Sa; else if (PHadj[Sal .left—2δδPHadj[Sa]Torthoσ—lδ PHadj[Sal .dist_left—

PHadj[0] .widthδδPHadj[Sal .width—48δδPHadj[Sal.dist orrhocr—O) Sσ- Sa; else if (PHadj [Sal .left—lδδPHadj [Sal .orεhoσ—lδδPHadj [Sa] .dist_ieft—o

PHadj[Sal.width—24δδPHadj[Sal .dist_orthoσ—24) Sb- Sa; else if (PHadj[Sa] .left—lδδPHadj[Sal .orchoσ—lδδPHadj[Sa] .dist_ieft==o

PHadi[Sal.width—24δδPHadj [Sal .dist crεftoσ— 8) Sc- Sa; else if (PHadj[Sal .left—2δδPHadi rs l .ortnoσ—lδδPHadj[Sal .dist_left==

PHadj [0] .widthδδPHadj [Sal .width—24δδPHadι ^' [Sal .dist orthoσ—0) Sd= Sa; else if (PHadj[Sal .left—2δδPHadj [Sal .crτhoσ _* -lδδPHadj ^" [Sal .dist_left==

PHadj[01. idthδδPHadi[Sal.width—24δδPHadj [Sal .dist orchoσ—24. Se= S else if (PHadj[Sal.left—lδδPHadj [Sal.orchoσ—OδδPHadj [Sa] .dist_ieft==-2

PHadj[Sa].width—24) Sh- Sa;

Appendix Page C- 1

eise if (PHadi [Sal .left==2δδPHadi TSal .orthog—OδδPHad [Sal .dist left==2 ₄ PHadj [Sa] .width—24) Sι= Sa; ^'

_J

: (PHadj [0] .width—48) if (Sf>0) HangMatc (17,0,Sf,0,0) ; if (Sg>0) HanσMatch(18,0,Sg,0,0) ; if (Sb>OδδSc>0) HangMatch(17, 0,Sb,Sc, 0) ; if (Sd>0δδSe>0) HangMatc (18.0,≤d,Se,0) ; else if (PHadj [0] .width—24) if (Sh>OδδSσ>0) HangMatch(18,0,S .Sg,0) ; if (Ξh>OδδSd>OδδΞe>0) HanσMatch(18,0,Sh,Sd,Se) if (Si>OδδSf>0) HanσMatch(17,0,Si,Sf,0) ;

.•_:.. -e. (Si>OδδSb>OδδSc>0) HangMatch(17 ,0,Si.Sb,Sc)

}

void SetV19_20() {

Sb= Sc= Sd= Se- Sf= Sg= Sh= Si= Sj= S = Sl= Sin- Sn= So- Sp- Sq= Sr= _S s= ₀ ; for (Sa-1; Sa<nuπ_PHadj ; Sa++) { if (PHadj [Sal .left==lδδPHadj [Sal .orthog—lδδPHadj [Sal .dist left—Oδδ

PHadj [Sal .width—30δδPHadj [Sal .dist_orthog«30) Sb- Sa; else if (PHadj[Sa] .left—lδδPHadj [Sa] .orthog—lδδPHadj[Sa] .dist left— ₀ &

PHadj [Sa] .width«30δδPHadj[Sa] .dist_orthog—60) Sc= Sa; ~ else if (PHadj[Sa] .left==2δδPHadj [Sa] .orthoσ—lδδ

PHadj [Sa] .dist_left—PHadj [0] .widthδδPHadj [Sa] .width—3Oδδ

PHadj [Sa] .dist orthog—0) Sd= Sa; else if (PHadj [Sa] .left=-2δδPHadj [Sa] .orthog—lδδ

PHadj [Sa] .dist_left—PHadj [0] .widthδδPHadj [Sa] .width~30δδ

PHadj[Sa] .dist_orthog—30) Se- Sa; else if (PHadj [Sa] .left—lδδPHadj [Sa] .orthog—Oδδ

PHadj [Sal.dist_left—30δδPHadj[Sa].width— 0) Sf- Sa; else if (PHadj [Sa] .left—2δδPHadj [Sa] .orthog—Oδδ

PHadj [Sa] .dist_left—30δδPHadj[Sa] .width—30) Sg- Sa; else if (PHadj [Sal .left—lδδPHadj [Sa] .orthoσ—lδδPHadj [Sa] .dist left—Oδ

PHadj [Sal.width—24δδPHadj [Sa] .dist_orthoσ—24) Sh- Sa; else if (PHadj[Sa] .left—lδδPHadj [Sa] .orthog—lδδPHadj[Sa] .dist left==o&

PHadj [Sal.width—24δδPHadj [Sal .dist_orthog—60) Si- Sa; else if (PHadj[Sa] .left—lδδPHadj[Sa] .orthog—lδδPHadj[Sa] .dist left==o&

PHadj [Sal .width—36δδPHadj[Sal.dist_orthog—36) Sj» Sa; else if (PHadj[Sa] .left—lδδPHadj[Sa] .orthog—lδδPHadj [Sa] .dist left—0&&

PHadj [Sa].width—3βδδPHadj [Sa] .dist_oιrthog—60) Sk= Sa; ~ else if (PHadj [Sa] .left—2δδPHadj [Sa] .orthog—lδδ

PHadj[Sa] .dist left—PHadj [0] .widthδδPHadj[Sa] .width—24δδ

PHadj [Sa].dist~orthog—0) SI- Sa; else if (PHadj[Sa] .left—2δδPHadj[Sa] .orthog—lδδ

PHadj [Sa] .dist_left—PHadj [0] .widthδδPHadj[Sa] .width—24δδ

PHadj[Sa] .dist orthog—36) Sm« Sa; else if (PHadj [Sa] .left—2δδPHadj[Sa] .orthog—lδδ

PHadj[Sa] .dist_ieft—PHadj [0] .widthδδPHadj[Sa] .width—36δδ

PHadj[Sa] .dist orthog—0) sn- Sa; else if (PHadj [Sa] .left—2δδPHadj [Sa] .orthog—lδδ

PHadj[Sa] .dist left—PHadj[0] .widthδδPHadj[Sa] .width—36δδ

PHadj [Sa] .dist~orthog—24) So- Sa; else if (PHadj[Sa] .left—lδδPHadj[Sa] .orthog—OδδPHadj [Sa] ,dist_left==-24

PHadj [Sa].width—24) SD= Sa; else if (PHadj [Sa] .left—lδδPHadj [Sa] .orthog—OδδPHadj [Sa].dist_left==-36

PHadj [Sal .width—36) Sq= Sa; else if (PHadj [Sal .left—2δδPHadj [Sal .orthog—OδδPHadj [Sa] .dist_left==36& . PHadj[Sal.width—24) Sr- Sa; else if (PHadj [Sa] .left—2δδPHadj [Sa] .orthog—OδδPHadj [Sa] .dist_left==2 δ

Appendix Page C-42

PKadT fSa ] , idth— 36) Ss;- Sa; sw tc f PKad j [ 0 ] . idt ) case 30: f (Sf>0δδSd>0δδSe>0) HanσMatch(20, o,Sf.Sd.Se) x (Sf>0&δSl>0δδSo>0) HanσMatch(20,0,Sf.Si.So) xf (Sf>OδδSn>0&δSm>0, HanσMatch(20, o,Sf,Sn,Sa) xf (Sσ>0δδSb>0δδSc>0) HanσMatchfl9,0,Sσ,≤b,Sc) if (Sσ>θδδSh>0&δSk>0) HangMatc (19.0,Sg,S .Sk) f (Sg>OδδSj>0&δSi>0) HanσMatcn(l9,0,≤g,S ,si) break; case 24: if (Sσ>0δδSd>0δδSe>0) HanσMatc (20,0,Sq,Sd.Se) ; (Sσ>0δδSl>0δδSo>0) HangMatch(20,0,Sq,si,≤o) ; f (Sσ>0δδSn>OδδS 0) HanσMatch(20,0,Sq,Sn,Sm) ;

£ (Ss ^" >0δδSb>0δδSo0) HangMatch(19,0,Ss,≤b.Sc) ; if (Ss>0δδSh>0δδSk>0) HanσMatch(19,0,Ss,Sh,Sk) ; if (Ss>0δδSj>0δδSi>0) HangMatch(19,0,Ss _f Sj,Si) ; break; case 36: if (SD>0δδSd>0δδSe>O) HanσMatch(20,0,Sp,Sd.Se) (Sp>0δδSl>0δδSo>0) HanσMatch(20,0,Sp,≤l,So) f (SD>0δδSn>0δδSm>0) HanσMatch.20,0,≤o,≤n.Sm)

1? (Sr_>OδδSb>Oδδ≤c>0) HanσMatc (19,o,Sr,Sb,Sc) (Sr>0δδSh>0δδSk>0) HanσMatch(19,o,sr,Sh.Sk) (Sr>0δδSj>0δδSi>0) HangMatch(19,0,Sr,Sj,Si) break;

void SetPHacrossML(COUNT num, COUNT farr) { if (0!-GetPHframe(num) ) err(ERR_XINT_ACT,84); initPHacross() ; UpdatePHacrossM (farr) ; )

void UDdatePHacrossML(COUNT farr) (

COUNT Sa, Sb; cnar oPH; for (Sa-O; Sa<86 Sa++) { if (Sa<PHframe. eight) { for (Sb-0; Sb<PHframe.width; Sb++) { oPH- PHacrossfSa] ; if (PHacross[Sa]>PHframe.used Sb] [Sa])

PHacrossfSal= ^' PHframe.use rsbl [Sal ; if (Sb<far δδPHacross[Sal—-100) PHacrossfSa]- oPH; ) ) else PHacross[Sa]= 0;

void SetPHacrαssMR(COUNT num, COUNT farr)

{ if (0!-GetPHframe(num) ) err(ERR_XINT_ACT,85) ; initPHacross i) ; . UpdatePHacrossMR(farr) ; , .. „ „ ,_.

Appenαix Page C-43

.is farrs

::- ^* :;τ sa. si. sc; zr.zz cPH:

£== PHframe.width; r:r rsa-0; Sa<86 Sa-t-fi f (Sa<PKfrasse.neισn ) fcr ,'Sb-O; Sb<PHframe.width; Sb+f) cPH- PHacrossfSal ;

_._! fPHacross.Sa.>?Hframe.used.Sbl rsal) PHacrossfsal- PHframe.useαfSbl [Sa ) ; _.f (S_3>Sc-_.arri&rHacross(Sa]—iOO) PHacrossfSa]= oPH;

) eise PHacrossfSal- 0;

void DoActVerci() >0 in order * *

void OoActFioorO

/* This functions is called from XME ϋ. c when ACTvarf XACTVERT1]>0 in order *

/* to cause the variable lXVERTOl to be set for menu logic. * if (0 !-GetT_isam(cur__frame) ) err (ERR XIOT_ACT, 301) ; initPHad ( ) ;

PHadi [ 0 ] . number- T isam. umber;

PHad} [ 0 ] . width- T Isam . gw ;

PHad (01.lefts o;~

PHadj[0 ) .orthog- 0;

PHadj(0] .dist_le « 0;

PHad (01. ist_orthog« o; numPHadi- l;

SetPHacross ( Hadj [ 0 ] . number) ; uc» 0 ;

Db- Xlvar f xlXDITEM . ; for (Da-o : Da<PHf rame. height; Da-πc)

. (

Dc« PHacross f Da ] ; if (Do-Db) uc-M- r Appendix Page C- 4

else Da= 30000; XivarfxlXVERTOl]- uc:

void HanσMatcr..'COUNT type, COUNT set_type, COUNT a. COUNT b , COUNT c: switc .set_type) case 0: SetPHacrcssiPHadj[01.nuaoeπ ; breajc: case i : SetPHacrcssK fPHadi [01.r.umaer.221 ; sreaK; case 2: SetPHaercssK .PHadi[0j .numoer .22) ; b eax; if ( :=GetPHframe.PHadi[a1.numoer) ) err(ERR__XINT_ACT.1000) ; if (PHad^[0] .wιdth=-24Ϊiset_tvpe>0) ^" ~ if fset rype—l) UpdatePHacrossM (8) ; eise UcdatePHacrossMRfB) ;

) else UcdatePKacrαss() ; if (bi=0)

{ if f 01 -GetPH rame i PHadj ( b 1 . numoer i ) err f ERR_XINT_ACT . 001) ;

UpdatePHacrcss ( ) ; if ^' (c.-O)

( if (0i-GetPH ramefPHadj[cl. umoer) ) err(ERR_XINT_ACT.1002) ;

UodatePHacross() ;

) maxvrtypel- ma_cV_PHacrcssιtype) ; defVftypej« defV_PHaercss() ; )

;

ma>ACTvarfxACT7ERT11-l-XlvarfxlXHITEKl ; aa— ^•

Appendix Page C-45

/* XINT_PH.C

/*

/* Funtions for manipulating and using PHframe records

all of the

nsY;

) if (New01d«NEW) SetPHadj ( ) ; if (Newθld«NEW&&Upnum»«ALL)

{ switch (TItype) Appendix Page C-46

case 1; rase 2:

"_'?dateT_isamθ ame(Tg ,TgD, le _r=_ie t.Tr. moer.T eft; ; areajc; case 3: case 4 : if (0:=GetT_isam (Torddes) ) err!ERR_XINT_?H.132) ; crdDframel= τ_isam.Dframel: cr Dframe2= T_isam.Dframe ;

_.frameϋp= 1; crease;

if (Tgrapnic>122&&Tgrapπic<129) i.

UpdatePHad PHframes.Tg ,2,TgD,TIccZ.Tmite .Tleft_tc_left,Upnumι ; f (Tsιter 0)

! if (Tleft)

eise

{

UDdatePHadi PHf rames . TσD , TgH, Tg , TlocZ . Tmiter . Tlef t_t=_lef t , 'anumi

Tle t_tc_left+» TσW-2;

UpdatePHadjPHframes<2,TgH,TσD,TlocZ.Tmiter,Tleft_to_l eft.Upnum) ;

} ) else

(

UndatePHad PHframes.2,TgH,TgD,TlccZ, =iter,Tleft_to_left,Upnum) ;

Tlef t_to_le t+« TgW-2 ;

UDdatePHad j PHf rames ( 2 , TgH , TgD , TlocZ , Tmiter . Tlef t_to_lef t . Upnu ) ;

) ) else UDdatePHadi PHf rames (TgW , TgH , TcD , TlocZ . Tmiter. le t_ o_l eft , Upnum) ; if .01 =GetT_isam (Tnumoer j ) err ( EHR_XINT_PH . 100) ; f (Dframeϋp)

!

T_isam.Dframel= ordDframel; T isam.Dfram.e2s αrdD rame2; ir (Ol-SaveT_isamιO D) ) err(ESR_XINT_PK.13 ) ; ) } void SetPHadjO

{ startE rame- T_isam.number; initPHad O ; numPHadj« 0;

PHadj[01.numoer" startE rame;

PHad [0 ).wιdth= T isam.σw;

PHadj [0].left* 0;

PHa j[01.orchog» o;

PHadj[01.dist_left= 0;

PHad}[01. ist_ortftog= 0; numPHad-j-M- ;

PHad Left ( ) ; if (01 «GetT_isam < startEf rame ) ) err ( ERR_X NT_PH . 10) ;

PHad ight ( ) ;

⁾ Appendix Page C-47

void PHadj Left C COUNT Pa,

LeftlsGood, dist_orthog, dist_left; unsiσned char orthog;

} ) else LeftIsGood= 0; )

void PHadjRightO

{ COUNT RightlsGood, dist_orthog, dist~left; unsigned char orthog; Appendix Page. C-48

^■ 13.

orrhog= o : dιst_crt.ιoσ= 0 ; dist_le = ^' T_isam. g ; Ri htlsGood ^β 1 ; wnile (RiσntIsGood&&numPHadj <MAXPHAD -1 ) f if (GetT_isamRight ( ) ) f switc (T_isam. σraphic) ( ^' case 120 :

PHadj [ numPHadj j . number-* T _^ isam. number ; PHad [numPHadj ] . ιdth= T_Isam. σ ; PHadj [numPHadj j . left= 2 ; if (orthog—O) f

PHadj [numPHadj] .orthoσ» 0;

PHad [numPHad ] .dist_left= dist_left;

PHad [numPHadj ] .dist_orthog= o; dist_left+= T_isam-g ;

] else

{

PHad [numPHadj ] .orthoσ= l;

PHad [numPHadTj .dist_ϊeft= dist_left;

PHadj [numPHadj ] .dist_orthog= dist_orthog; dist_ortnoσ-t-« T_isam.σW;

) numPHad ++; break; case 122: if (orthog»»0) dist_left+= 3; else dist_orthog+« ; break; case 121: if (orthog-*11 | (T_isam.cαncur=2£&T_isa__ι.condes»»2) | |

(T isan concur=«l&&T isam.condes«»i) ) RightIsGood= 0; else~orthog= 1; ~ break; default: err(ERR_XINT_PH,15) ; break; ) ) else RightIsGood= 0; ) }

COUNT GetT_isamLeft() ( COUNT ret, otherside, Orddes≤etDir, Le tcon; ret= 1; switch(T isam.graphic)

{ case 120: if (T_isam.nu___ber==LeastItemι |T_isam.cαncur=2) { θrddes≤etDir= l ; LeftCdn= l ;

Appendix Page C- 9

sise Or≤desSetDir= 0; =reaκ; :2se 12 : -z .?_isa__.ccr_αes»i,

Cr≤desSecDir= 1;

_._ ^" : ,"_'_i_.aιn.concur==l) __eftccn= 2, eise __e_:tCsn= 1; sise θrddesSetDir= 0 ; ~reaκ: :ase 122: : (T__

Orddes≤etDir= l; if (T_isam.c3ncur»l) LeftCon= 3 ; eise eftCan= 1; j eise θrddesSetDir= 0: orea ; default: err(ESS XIHT_PH,12) ; crea_c: ~ ) if (CrddesSetDir)

Others ide» 0; cpyouf ftarσ,&T_isam. numoer.2, ; if (0»-FRSSET(T ISAMORD. T_rSMKEY(T ISAMORD, targ) ,&old_T_isam,2) ) ( cpybuf fiT_isam. &old_T_isam.T_ISAMRECI_EN> ; if (T_is<am.condes~ eftCcnfi-iT isam.grapnic>119&&T_isam.graphic<l23) otl_erside» T_isam. numoer: ~ else ( while (OtherSide—O&fiO— NXTSET(T ISAMORD , &old_T_isam) ) ( cpybuf r -T_is.am . &old_T isam . T_ISAMRECI_EN) ; if (T_isam.eonάes— __e£tCon&£T_isam. raphic? ll9&ST_isam.grap__ιc< 123) otherside _* T isam. numoer: ) ) if ( others ide—o) ret- 0; ) else ret« 0;

) else

{ if (0_»GetT_isam(T isam. orddes ) ) ret« 0;

) return (ret) ; )

COUNT Getτ_isamRigh () { COUNT ret, otherside,

OrddessetDir,

RightCoπ; re * l; svιtci_(T isam.graphic)

( ^{case 120:} Appendix Page C-50

r.ιgntccn= 2 ; eise OrddesSetDir= 0 : -treax: case 121: (T_isam. ccndes«-2 )

OrddesSetDir= 1;' f (T_isam.ccncur=l) Rightcon= 2; eise RightCon= 1; eise OrddesSetDir= 0; oreajc: case 122: f (T_isam.ccndes»»2)

(

OrddessetDir= l; f (T_isam.concur»»i) RightCon= 3; else RiσhrCon= I; i eise 0rddes≤etDir= 0; breax; default: err . ERR_XINT_PH , 13 ) ; oreaJe; ) if (Orddes≤etDir) { others ide» 0 ; cpybuf(targ,&7_isam.number.2 ) ; if (0=»FRSSET(T ISAMORD,T7RM EY(T ISAMORD,targ) ,&old_T_isam,2) )

{ cpybuf f £T_isam .4old_T_isam . T_ISAMR£C ΞN) ; if (T_isam. condes« _™ sightCon&£T_isam.graphic>119&£T_isa___- graphic<123 ) others ide* T_isam. number: else ~

{ while (0therSide~0&&0~NXTSET(T_ISAMORD, &old_T_isam) )

( cpybuff£T_isam.£oid_T_isam. _ISAMRECI_EN) ; if (T_isam.ccnαes»RightCon&&T_isam.grapnιc>119&&T_isam.gr apnιc<l22,

Othersιde» T_isam.nύmaer; ) ) if (otherside—o) ret- 0;

) else ret» 0;

) else

( if (0_»GetT_isam(T_isam.orddes) ) rer« 0; } return(ret) ;

) void UpdatePHadiPHframestunsiσned char gH, unsigned char gH, unsigned c.-.ar =D, unsiσned cnar iccZ, unsigned cnar miter, COUNT left to_left, COUNT Upnu )

( iT= locZ; iB« locZ-gH; for (Ua ^« θ ^; Ua<num_?Hadj ^; Ua++) Appendix Page C-51

.1 ^R_

( if ( ^τ pnum=»A L! |Upnum=«=PHadj [Ua] .number) if (0!=GetPHframe(PHadj [Ua] .number) ) err(ΞRR_XINT_?H,20) ; if (PHadj [Ua] .orrnog∞o) iD= 0; ι.M= 0; ιL-= left_to_left-PHadj [Ual .dist_left; ιR= i +gW; ) else

I if (PHadj[Ua].left==l)

{ iD= left_to_left-PHadj [Ua] .dist_left; if (miter—1) iM» 1; else iM» 0; i_ PHad [Ua] . ist_orthog-gD; iR= PHadj [Ua] .dist_orthog;

) else

{ iD* PHad [Ua].dist_left-left_to left-gW; if (miter-»2) iM- l; ~ else iM« 0; iL» -l*PHadj[Ua].dist_orthog; iR= iL+gD;

) ⁾ PHw= PHframe.width; PHh= PHframe.heiσht; if (i <PHw&&iR>0&&iB<PHh) { if (iL<0) w_start» 0; else w start ⁵ * iL; if (iR>PHw) w_end- PHw; else w_end«* iR; h start= iB; iϊ (iT>PHh) h_end- PHh; else h_end» iT; for (Uw»w start; Uw<w_end uw++)

( for (Uh-h_start; Uh<h_end Uh++)

( if (Uw>«i &&Uw<iR&fiUh>»iB&&Uh<iT)

{ if (iD<6&&iM) PHframe.used[Uw] [Uh]= -100; else if (iM~0)

( if (PHf ame.used[Uw] [Uh]>iD) PHframe.used[Uw] [Uh]= iD;

) ) ) ) if (0!-RWTREC(PHFRAMEDAT,&PHframe) ) err(ERR XINT PH,21) ;

)

void NewPHframelnserted() if (0!=GetPHframe(T_isam.number) ) err(ERR_XINT_PH,399) ; NewPHframe- PHframe.number;

Appendix Page C-52

_Br .

- ^«' ~_isam.αes'c____r-_me ^» "?rew_Pjϊadτ_.ujscersf Na] ) fT_isam. ncdrav»»o& ST_isam . nεiσn r 2. > 0 ) -αdarePHf rame-rcmT^sam ( CLΞ . i.ewPH ame i ;

^* °ϊ_f ' ^≤aceT - ^i≤aπD -5r23eιur.sιc eα c.-.ar σw, nsiαπeα cnar ca, CCUNT " ^■ eft -- _l e _ft ^" " _—_ ^•■• = ^{•>■•■} " .600 _. ;

"b= 0: z.2 (PHadi [Ua.. CΠSM— o ) ι = left_ts left-PHad [Ual .disc left; iR" IJ-TOWJ ~ -

0b» 1; ) else

{ if ⁽ PHad [Ua] .laft=lSiTleft ^β -os_.f (T_isam-σraoaic5i2Sti τ_ιsam_grapnιc<l23) | | (T_isam.grapnιcr>i41-.iT_isam_grapnιccl46) ) ) i - PHadi [Ual.disr cr-shoα-gD; iR- PHadi ( Ua 1. disr~=rraoσ ; Ub» 2; ~

) else ⁱ f ⁽ PHad [Ual .laft—2SfiTleft ^« -ι&4. (T_isam_σranaiol28« - ιsam.σrapaιc<i23 ⁾ I | (T_isam.grapnιcj>i4l&4T_ιsam.grapaιc<-i46) ) ) iL= -i.*PHad} [U l. disc czrzϊiaa: iR- ιLt-gθ;

Ub- ;

) ) if (Ub>0) ( PHw- PHadj [Ual. width; if (i <PHW44 R 0) switc (Ub) { case 1: swirchfUc) ( case ⁰ : T_isam.Bframel- PHadi f al .numoer r breaie; case i: τ_isam.s_.rame__~ PHadj [Uaj -numoer; creaj.;

UCΉC? ^brβaJt: Appendix Page C-53

case 2; case 3: break;

) if (ϋc>0) if ^(0! =SaveT_isam(OLD) ) err(E3__R_XINT_PH, 602)

Appendix Page C-54

'* Funtiens fcr serrir. worscsur ace and fraesranding variable values void Setsus VarfCOCIϊ set) f (7_isam.grannie?122£&T_isa__._graBnιe<129)

Tnu_a= T isam.numoer; TgD= T_Tsam.gθ; TgW- τ_isam.σ ; Tlocz= T_isam.lccZ; Tcαneur=~ ^* T_isam.concur; Kdiαz= TlocZ-2; if (ser)

( if (O.-GetT isa fT isam. estE rame) ) err(ERR XINT S.O); SetPHadjO ;~ } if (Tconcur—3) left_zc_left= -l*(TgW-PKadj[0] .width) ; else left_to_left= 0; for (Sa-0; Sa<HDIG __2T; Sa++) Hdig[Sal» 0; for (Sa-o; Sa<numPHadi Sa-t-c) { if (PHadj[Sa1.αrtftoσ—0) (

Sb- PHadi[Sal .dist_left-left_rc_left; if (Sb>«όfi-.Sb<TgW) { if (01-GetPHframe(PHadi[Sal.number) ) err(-_3R_XH-T WS , 1) ; for (Sc-O; Sc<PHadj[Sal.width; ≤c-i ) ~

{

Sd- 0; for (Sβ-TlocZ-3; Se>-0; Se—>

(

Sf- PHframe.used.Se][Se. ? if (Sf>« σD) Sd++; else Se- -30000;

) if (Sb+Sc<TgW) Hdig(Sb+Sc)» Sd; else Sc— 30000;

)

) Sa- 0; Sb- 0: Sc- 0; Sd- 0;

Xlvar f5_lXSUSP021- 0; Xlvar(xlXOTSP08i- 0; Xlvarfj_lXSUSPl4 i« 0; XlvarfxlXSϋSP20]- 0; for (Se-0; Se<TgW Sβ-i→)

{ if (HdigfSe)>-2) Sa-t-c?- else Sa- 0; if (Hdig[Se)>-8) Sb*+? else Sb" 0; if (Hdig(Se.>-l4) SC-M-Γ eise Sc- 0; if (Kdig[Sei>-20) Sd++? else Sd- 0: if (Xlvarfs_ixSUSP02 KSa) XlvarfxlXSϋSP021= Sa; if (Xlvar. jαxsusP08i<Sb) xivarfjαxsuspos 1- sb; if (Xlvarfj_lXSUSP14 i<Sc> XlvarfxlXSUSP14 i« Sc; if (Xlvar£j_lxsuSP2θi<Sd) Xlvar(xlJ£≤ϋS?20i- Sd;

) if (0i ^» GetT_isam(Tnum)) err(ERR XlNT_ws,5) ^; Appendix Page C-55

vo id SetFreeVar ( )

COUNT Sa , Sb , Sc , Sd , Se ,

Tnum; if (T_isam.graphic==120)

HdigZ= - 1 ;

Tnuά= T isam. number ;

SetPHadJO ; for (Sa=0; Sa<HDIGLEN Sa++) Hdig[Sa]= 0; for (Sa»0; Sa<numPHa j ; Sa++)

( if (PHadj[Sa] ,orthog»«0&&PHadj[Sa] .left!=l)

{

Sb= PHadj [Sa1.dist_left; if (Sb>=θ&&Sb<HDIGLEN)

{ if (o!=GetPHframe(PHadj [S ] .number) ) err(ERR_XINT_ S,6) ; for (Sc=0; Sc<PHadj [Sa] .width; Sc++) ~~

{

Sd= 0; for (Se«0; Se<PHframe.height; Se++)

{ if (PHframe.used[Sc] [Se]>=20) Sd++; else Se ^β 30000;

) if (Sb+Sc<HDIGLEN) Hdig[Sb+Sc]= Sd; else Sc= 30000; ) ) ) ) Sa» 0; Sb» o; Sc« o; Sd» 0;

Xlvar.xlXFR£E24]= 0; Xlvar[X1XFREE27]= 0; Xlvar[X1XFREE42]= 0; Xlvar.X1XFREE541- θ; for (Se«0; Se<HDIGL£N; Se++) { if (Hdig[Se]>»24) Sa++; else sa- 0; if (Hdig[Se]>=27) Sb++; else Sb= o; if (Hdig[Se]>«42) Sc++; else Sc» 0; if (Hdig[Se]>»54) Sd++; else Sd= 0; if (Xlvar[xlXFREE24]<Sa) Xlvar[xlXFREE24]= Sa; if (Xlvar[xlXFREE27]<Sb) Xlvar[xlXFREE27]= Sb; if (Xivar(xiXFREE42]<Sc) Xlvar[X1XFREE42]= sc; if (Xlvar[xlXFREE54]<Sd) Xlvar[xlXFR£E54]= Sd; ) if (0!=GetT isa (Tnum)) err(ERR XINT WS,5) ; ) ^"

)

void SetBelowVar() { if (T isam.height[2]==1)

( •

Do e[0]= T_isam.destEframe; Appendix Page C-56

DoMeri]= T_isam.Dfrai_.el: DoMe (21= T_isam.Dframe2; raaxn= ioo; for (Sa-O; Sa<3 ; Sa++) t if (DoMerSa] i=0) if ( 0 ! =GetPHf rame ( DoMe [ Sa ] ) ) err ( ERR_XINT WS , 50 ) ; for (Sc=θ; Sc<PHf rame. width; Sct+) ^~"

(

Sd= 0; for (Se-T_isam.locZ-T_isam.gH-l; Se>«0; Se— )

{

Sb- PHframe.usedrSc] [Se] ;

Sf- T_isam.gD; if (Sb>«Sf) Sd++; else Se- -30000;

) if (maxh>Sd) maxh- Sd;

) ) ) } XlvarfxlXVERT01]= maxh; }

Appendix Page C-57

* X N DEL.C */ * ^— *' * Funtion fcr deleting an item from an interior design dataoase DV */ * metnod one. ^' * void DeletelnteriorByNumper (COUNT DeleteNumoer)

SSe .numSel- 0;

Upnum- 0; tήeorαdes- o; tneconαes- 0; thetype- 0: nextLeast- 0; nextordltem— 0r leaveordltem- ordlte ; canDelete- 1; if (0.-GetT_isam(Delete_.umber) ) err(ERR_XINT_CΞL,43) ; if (T_isam.numoer—Leastltem)

{ canDelete- 0; while (canDelete—0&&0—NXTREC(T_ΣSAMNUM,&T_isam) ) if (T_isam.type—ACTIVE&&( (T_isam.graphic—1201 IT_isam.graphic==121! ! T isam.σraόhie—122) I | (T_iIam.αestEframeJ-Delete_.umoer&& ^' T_isam.Dframel!-Delete-.un_Der-ι&T_ιsam.Dframe2!-Deletet-u moer) ) )

\ nextLeast- T isam.number; canDelete- lT } ) if (0!»GetT_isam(DeleteNumber) ) err(EHR_XIOT_DEL.1 3) ; ) if (canDelete) ( if (DeleteNumber—ordltem) ( if (DeleteNumtaer!-Leas lte ) nextordlte - T_isam.orddes; else nextordltem- nextLeast; leaveordltem- nextordltem; ) thetype- T_isam.type; tneorαdes- T_isam.orddes; thegrapnic= T_isam.graohic; tneαestEframe- T_isaα.riestEframe; theDframel- T_isa-.DframeA; theDframe2- T_isam.D rame ; if (OJ-GetItem<Delete_.umoer)) err(ERR_XINT_DΞL,151) ; RestoreIvar() ; theconαes- litem.Uvar[I lAss+xlACONDES] ; if (nextLeast>0) ~ {

Leastltem- nextLeast; cpybuff arg,&T_isam.number.2) ; if (0!-FRSSETf _ISAMORD.TFRMXEY(T_ISAMORD.targ) ,-old T_isam,2) ) err(ERR_XINT_DEL.333); cpybu (&T_isam,&old_T_isam,T ISAMRECLEN) ; if (T isai.type!-ACTIVE) ~ (

DCa- 1; while(DCa) ( if ( 0 ! «NXTSET (T_ISAMORD , &αld_T_isam) ) err(ERR_XINT_DEL.334 ) ; cpybuf f£T_isam. &old_T isa__. T_ISAMRECLEN) ; if (T_isam. ype— ACTIVE) DCa- 0 ;

) Appendix Page C-58

if .o.-GetItem.T_isam.numoer) ) err.ERR_X :iT_DΞL.235) ;

T _^ isam.aeietaDie— 1; litem.deletaole— 1; f (litem.UvarfI_IAss+xlAC0HCUR1<9) for (DCa-0: DCa<EI_sX8I DCa+-t-. litem.UvarfI_8ss+(9*DCa)+ lite .UvarfI_lAss+xiACONCUR] ]= 0; if (litem.Uvarfl IAss+xlACONCUR]<5)

{ for (DCa-0; DCa<EI_sX I; DCa++) litem.Uvar(I_4ss+(5*DCa)+ lite .Uvarfl lAss+xiACONCUR. ]= 0;

) if (litem.UvarfI_lAss+xlACONCUR1<3)

. for (DCa-0; DCa<EI_sX2I DCa++) Iitem.Uvar(I_2ss+(3*DCa)+ Iitem. uvar f I_l__5s+xlAC0NCirR] ] = 0 ;

T_isa__..neigiι flitem.Uvar[I_lAss+xiACONCUR]-π- o;

} if (0!=RWTVRECfrrEMDAT.&Iitem.I_len)) err(ERR_XINT DEL,336) ; if (0!=SaveT_isam (OLD)) err(ERR_XINT_DE ,336); } else

{ if (OI=GetT_isamttiιeorddes) ) erτfERR_XINT_DΞL,1 5) ; if ( 0 ! -Getltem t ttteorάdes ) ) err f ERR_XI _DEL.146); if (tiiεtype— ACTIVE)

{

T_isam.deletable— 1; litem.deletable— 1;

if . nex_Leasr>o . Leastltem* nexrLeast; f (Q ! =GetT_isam. DeleceHumDer. ) err(ERR_XINT_DEL. 24 ) ; eise Upnum* rhedestE rame; KililnterιorT_isam() ;

DCc= theorddes; ) else if (nextordltem>0)

{ if (0!*GβtT_isam_nextordltem) ) err(£RR_XIHT_DEL,158) ; Drawτ_isam.UD_HIGHL) ; DCc* nextordltem; } if (thedestEf amei«Delete u___oer&ithedestEframeι=theorddes)

{ if (0!*GetT_isamfthedestEfra___e) ) err(ESR_XINT_DEL.1040) ;

DrawT_isa.a<ϋD_0N) ;

) if (theθfraaei_*θ)

{ if (0_«GetT_isamftheDframel) ) err(ERR XINT_DEL.1041) ;

Dravτ_isam(UD ON) ; ~

) if (tώβθfra_nβ I«0)

{ if (0I-GetT_isa__._theDfra__.e2) ) err(ERR_XIOT_D£L,1042) ;

DrawT isaa(UD ON) ;

} for (DCa*θ; DCa<SSet.πu___Sel; DCa++)

( cpybuf. fiDCb.&SSet.var(DCa*2] ,2) ; if (DCbi-DCc) { if (0!*GetT_iS-U_ιrDCS) ) err(ERR_XINT_DEL,3000) ; DravT isam(UD_ON) ; }

) if (thegraphic*»i20)

( for (DCa*θ; DCa<nu_aEframe DCa++)

{ if (EframefDCa] [Oj—DeleteNumber)

{ for (DCb*DCa; DCb<nu_n£frame-i; DCb++)

{

E ramefDCb][0]= EframefDCb+1. [0] ;

Eframe. DCb. [l]= EframefDCb+π [1] ;

EframefDCb ) [2]= Efr.ame DCb+i ) [2] ;

) nuaE ra e-- ? DCa- 30000 ; )

> Appendix Page C-61

)

if (Upnum1=0) DeletelntPH rameUpdate(Upnum; ; else err(ERR_XINT_DEL,6600) ; ordltem* leaveordltem;

Appendix Page C-62