As mentioned above, installed command history plug-ins are invoked when specific events occur in Alias. Implementing a command history plug-in involves deriving a new class from AlUserCommand and implementing the bodies of the necessary methods of the new class. Below is an outline of the necessary components of a command history plug-in:

• Command history plug-ins require constructor and target DAG nodes. It is a good idea to encapsulate these items into a small class, since this data will be passed to the store code and received from the retrieve code.
• Create a new command class by deriving from the AlUserCommand class. The new command class must implement these methods:
  • ::isValid() so that Alias can determine if your command history plug-in can be executed.
  • ::execute() so that the command plug-in can control how the target objects will be rebuilt.
  • ::declareReferences() so that the command history plug-in can inform Alias which DAG nodes are the constructors and targets. This method would use the methods addConstructorRef() and addTargetRef().
  • ::instanceDag() to handle the case of if a user instances a dag that is a part of the command history object.
  • ::dagModified() and ::geometryModified() to rebuild the geometry. (The linkObjectExample.cpp command history plug-in implements only dagModified() currently.)
  • ::listModifiedDagNodes() to inform Alias about dependencies on other DAG nodes
  • ::storeWire() and ::retrieveWire() so that Alias can save and retrieve the construction history data from wire files. These methods use the command data class that store the constructor and target DAG nodes.
• Command plug-in data is stored in Alias wire files. Alias can load a wire file that contains command plug-in data.
  • If the plug-in is already loaded, the command is reinstated for the objects.
  • If the plug-in is not loaded, Alias displays a message on the prompt line, indicating that the plug-in could not be found. If the wire file is re-saved, the command plug-in data is also re-saved.
• Moving a target node produces a confirm box asking if it is OK to break construction history. This is necessary since the targets are based on the state of the constructors and not the other way around.
• It is safer to change the geometry of the targets than to delete and recreate them when updating the objects. This avoids problems with animation.