There are three kinds of tools in Alias: momentary functions, continuous functions and construction history functions.
A momentary function is essentially a single event: a function that takes no arguments and has no return value. It is simply a jump point in memory. Alias transfers control to this point when the menu item is invoked, the function executes, and control is returned to Alias. An example of a momentary function is ‘delete all’.
The simplest way to define a momentary function is through the AlMomentaryFunction class. Calling one of the create methods on an instance of that class will generate a new momentary function in Alias.
A continuous function is more complicated than a momentary function. It is event driven: it must respond to user interaction through the mouse, keyboard, and user defined devices. As a result, continuous functions do not actually take over control of Alias when they execute. Rather, they define a context under which UI events are interpreted. Alias reads these events and transfers them to a group of event handlers defined by the continuous function. Thus a continuous function is a set of five callback functions: init, mouse down, mouse move, mouse up and cleanup.
In addition, a continuous function is allowed to define pre-init and post-cleanup functions. The reason for these is that there are two ways to enter and leave the context of a continuous function. The function can be preempted temporarily by selecting some momentary function, or terminated more permanently by switching contexts to some other continuous function (or quitting Alias, of course). The pre-init and post-cleanup functions allow you to define actions that get invoked when Alias truly changes contexts and does not merely preempt your continuous function.
“Init” is executed when the context of a continuous function is entered. This occurs when the function is first invoked, or after returning from a momentary function which pre-empted the function, or after reselecting this continuous function after completing some other continuous function.
“Down” is called on every mouse down event. Use this function to detect the start of a click-drag type of operation.
“Move” corresponds to the sequence of mouse movement events that occur between a mouse down and a mouse up. A move event is generated for each significant mouse movement while a button is being held down. Further, “move” is called in the case that the enter key is pressed on the keyboard. Therefore, it is in the move function that keyboard input should be detected.
“Up” is called on mouse up events. Use this function to do things like commit transforms or create geometry corresponding to some sequence of mouse drags.
“Cleanup” is called when the context of this function is left to perform some other action. For example, if the user is in the context of your continuous plug-in, and invokes some other momentary function, the cleanup function is called, followed by the momentary function, followed by the “init” function when Alias returns to the context of the original continuous function.
Command history plug-ins are very complex, and it is advisable not to attempt creating one until you have a firm understanding of momentary and continuous plug-ins.
Command history plug-ins are not menu-based but rather are invoked when geometry changes. You install a command plug-in by selecting a menu item. This calls plugin_init() to install the command in Alias. Once installed, the command plug-in can run without your reselecting the command plug-in menu item.
A command or construction history object has knowledge of how it is created. The constructors of the object are tracked as well as the targets (outputs) of the command. When a constructor is modified, the geometry of the targets are rebuilt. A command history plug-in would program the behavior of the modifications of the targets based on the changes of the constructors.
See the documentation on AlCommand, AlUserCommand, and AlNotifyDagNode, as well as the examples constrainCVExample.cpp and polyHistoryExample.cpp.
When you are modifying geometry, the doUpdates() method of the geometry should be called with FALSE, and never called with TRUE. This is necessary since the command is being called from within the message system and updates generate messages. If updates are done during a command, then unnecessary messages are generated and that could create a loop where the command is responding to a message it generated.