Named Variable Holding an Expression
The Associative Framework provides an action class for representing an object that has a name, arithmetic expression and current value. The expression can reference any objects that expose AcDbAssocValueProviderPE protocol extension, including other variables (because variables also expose this protocol extension). The AcDbAssocVariable owns read only AcDbAssocValueDependencies on these objects.
Because AcDbAssocVariable is an action, it is owned by an AcDbAssocNetwork as any other action, and the Associative Framework guarantees that the variables are evaluated in the correct order, based on the order the expressions in variables reference other variables. Cyclical dependencies are not allowed.
The AcDbAssocVariable class is somewhat different from pure actions because it is both an action and also keeps a value. Pure actions just perform an operation on some other objects, but do not keep values, the values are kept by the objects the action has dependencies on.
The AcDbAssocVariable has an implied write only dependency from the variable "action" on the variable "object". The implied dependency represents the fact that evaluating the variable action changes the variable object. This implied dependency is not a real object in the database, but all the algorithms assume that this implied write only dependency is the first dependency in the list of dependencies on the variable. The concept of an "implied" write only dependency of the action on itself is not only for variable action, it is used for any action objects that have dependencies attached to them.
Set of Geometric Constraints between Entities on Plane
The Associative Framework provides a built in action class for representing a set of geometric constraint relations between geometries in a plane, such a coincident, parallel, perpendicular, tangent, concentric, distance, radius, or angle constraint. The evaluation of an AcDbAssoc2dConstraintGroup action first obtains the current coordinates of the referenced geometries, after that it calls a constraint solver to find new coordinates of the geometries so that they satisfy the given constraints, and at the end updates the coordinates of the referenced geometries.
The AcDbAssoc2dConstraintGroup owns the following dependencies:
- "AcDbAssocGeomDependencies on the subentities of the constrained AutoCAD AcDbEntities. If the entity is allowed be changed by the Constraint Group action, the dependency is read write. If the entity is not allowed to be changed by the Constraint Group action, the dependency is read only.
- "Read only AcDbAssocValueDependencies on AcDbAssocVariables that provide distance and angle values of the dimensional constraints. For reference "constraints" that just measure the geometries and do not impose any constraints, the AcDbAssocValueDependency is write only, because the variable is set with the measured value.
- "If dimensional constraints use AutoCAD objects or entities (such as AcDbDimension entities) as graphical representation of the dimensional constraints, the Constraint Group action also owns AcDbAssocDependency objects that own objects derived from AcDbAssocDimDependencyBodyBase. They facilitate the interaction between the dimensional constraints, the AcDbAssocVariables that keep values of the dimensional constraints, and the graphical representations of the dimensional constraints, such as AcDbDimension entities.
The solving of a set of geometric constraints on a set of geometries is analogous to solving a system of equations. The geometries correspond to variables, the constraints correspond to equations. The geometric constraint solver tries to find such values of the geometries so that the constraints are satisfied. The constraint system may be under constrained, when the constraints allow an infinite number of possible geometric configurations, fully constrained, when there is only one (actually, only a finite number of) possible configurations of geometries allowed by the constraints, or over constrained, when there is no configuration of geometries that would satisfy the given set of constraints. Notice that the three above states are not mutually exclusive. The constraint system may be at the same time under constrained for some geometries, fully constrained for some others, and over constrained for the rest.
Associative Surface Modeling
The associative surface modeling functionality is implemented by action bodies derived from the AcDbAssocSurfaceActionBody class. The base class keeps a dependency to the resulting AcDbSurface entity. The “creation actions” set the initial contents of the surface and have a write-only dependency on the surface. The “modification actions” modify the contents of the surface and have read-write dependency on the surface. There may be only a single creation action on the surface and it must be the very first action in the list of actions on the surface. The surface may have any number of modification actions.
Examples of creation actions are
- AcDbAssocExtrudedSurfaceActionBody
- AcDbAssocBlendSurfaceActionBody
- AcDbAssocOffsetSurfaceActionBody
Examples of modification actions are
- AcDbAssocTrimSurfaceActionBody
- AcDbAssocFilletEdgeActionBody
Some actions may act as a creation action on one surface and as a modification action on other surfaces. For example, AcDbAssocFilletSurfaceActionBody is a creation action of the resulting fillet surface, but it may also act as a modification action on the two input surfaces, if the input surfaces are to be trimmed by the fillet operation. If it is a modification action on the input surfaces, it has read-write dependencies on them. If it is not, it has read-only dependencies on the input surfaces.
AcDbAssocExtendSurfaceActionBody may either be a creation action or a modification action, depending on whether it extends the existing surface or sets the contents of another surface to be the extension. In the former case, the action has a read-write dependency on the surface that is extended. In the latter case, it has a read-only dependency on the input surface and a write-only dependency on the resulting surface.
If a surface does not have a creation action but a modification action is going to be applied to it, an internal (not exposed in ObjectARX) AcDbAssocRestoreEntityStateActionBody creation action is automatically inserted as the first action on the surface. The restore action keeps a backup copy of the initial state of the surface, before any modification actions have been applied to it. The evaluation of the restore action just restores the contents of the surface from the backup.
During action evaluation, the surface is first restored to its initial state by evaluating the restore action, and after that the modification actions are evaluated and they modify the surface.