An event is an action that takes place in the environment in which we operate, in our case the AutoCAD application or in a more general sense, the computer. Obviously, not all actions that may occur while running an application deserve the same attention. The applications programmers are the ones who decide what actions deserve to be taken into account. Visual LISP has access only to events raised within AutoCAD.
 |
| Inspecting a Reactor |
A reactor is a special object that can be linked to another object in the drawing, even the drawing editor itself. This reactor is responsible for notifying our program when the event we are interested in is raised. If an entity linked to a reactor is modified, the notice of such modification can be used by the program, for example, to modify in the same way (moving, scaling, etc.) other entities that have been associated to the one that causes the event notification.
A reactor communicates with the application by calling a function that our program has associated with that reactor. These types of functions are known as callbacks. These are normal functions (although with certain limitations) that become callback functions when linked to a reactor’s events.
AutoCAD has increased the role of reactors within the application. Features like parametric design or associative surfaces are implemented using the reactor technology.
The functions used for everything related to reactors are identified by the vlr- prefix. These functions are part of the Visual LISP ActiveX extensions requiring a call to vl-load-com before they can be used. A prefix search using Apropos reveals that there are 47 such functions. Although addressing a topic so prolific in functions may seem a bit overwhelming, it’s actually not so difficult once the basic mechanism is understood. This does not mean that their use is simple, and not even justified. The abuse of reactors can slow down our system, especially in the case of reactors triggered by editor events that may be continuously raised. It may even be the case that the effect of other reactor triggers actions which in turn will trigger the original and so on, originating an endless loop. And many things that in Release 2000 could only be implemented using reactors are now built into the application’s standard features.
With each new release more and more commands are based on reactors functionality with no need for programming. Until recently, establishing geometric relationships between objects so that changing the orientation of one would automatically modify the orientation of the other was among the most widespread demonstrations of reactors programming. This can be done today applying geometric constraints, without a single line of code.
This Chapter includes the following sections:
21.1. The VLR functions.
21.2. Events that trigger a reactor.
21.3. Actions.
21.4. Tutorial: An application using Reactors.
21.5. Enabling persistent reactors functionality.
21.6. Summary.
Chapter 21 Source code.
Your questions or comments about this Chapter's contents are welcome!
Buy this book from Amazon
No comments:
Post a Comment