Reactor Use Guidelines

AutoLISP Developer's Guide > Using the Visual LISP Environment > Advanced Topics > Attaching Reactors to AutoCAD Drawings >

When using reactors, try to adhere to the following guidelines. Reactors that violate these guidelines can result in unpredictable results for your application if the internal implementation of reactors changes.

Do not rely on the sequence of reactor notifications.
It is recommended that, with a few exceptions, you do not rely on the sequence of reactor notifications. For example, an OPEN command triggers BeginCommand, BeginOpen, EndOpen, and EndCommand events. However, they may not occur in that order. The only event sequence you can safely rely on is that a Begin event will occur before the corresponding End event. For example, commandWillStart() always occurs before commandEnded(), and beginInsert() always occurs before endInsert(). Relying on more complex sequences may result in problems for your application if the sequence is changed as a result of new notifications being introduced in the future and existing ones being rearranged.
Do not rely on the sequence of function calls between notifications.
It is not guaranteed that certain functions will be called between certain notifications. For example, when you receive :vlr-erased notification on object A, all it means is that object A is erased. If you receive :vlr-erased notification on A followed by a :vlr-erased notification on B, all it means is that both objects A and B are erased; it does not ensure that B was erased after A. If you tie your application to this level of detail, there is a very high probability of your application breaking in future releases. Instead of relying on sequences, rely on reactors to indicate the state of the system.
Do not use any interactive functions in your reactor callback function (for example, do not use getPoint, entsel).
Attempting to execute interactive functions from within a reactor callback function can cause serious problems, as AutoCAD may still be processing a command at the time the event is triggered. Therefore, avoid the use of input-acquisition methods such as getPoint, entsel, and getkword, as well as selection set operations and the command function.
Do not launch a dialog box from within an event handler.
Dialog boxes are considered interactive functions and can interfere with the current operation of AutoCAD. However, message boxes and alert boxes are not considered interactive and can be issued safely.
Do not update the object that issued the event notification.
The event causing an object to trigger a callback function may still be in progress and the object still in use by AutoCAD when the callback function is invoked. Therefore, do not attempt to update an object from a callback function for the same object. You can, however, safely read information from the object triggering an event. For example, suppose you have a floor filled with tiles and you attach a reactor to the border of the floor. If you change the size of the floor, the reactor callback function will automatically add or subtract tiles to fill the new area. The function will be able to read the new area of the border, but it cannot attempt any changes on the border itself.
Do not perform any action from a callback function that will trigger the same event.
If you perform an action in your reactor callback function that triggers the same event, you will create an infinite loop. For example, if you attempt to open a drawing from within a BeginOpen event, AutoCAD will simply continue to open more drawings until the maximum number of open drawings is reached.
Verify that a reactor is not already set before setting it, or you may end up with multiple callbacks on the same event.
Remember that no events will be fired while AutoCAD is displaying a modal dialog.