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.
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:
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.
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
Examples of modification actions are
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.