When using reactors, you need to make sure your reactors follow a set of guidelines to make sure they do not produce unpredictable results for your application if the internal implementation of reactors changes.
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.
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.
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.
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.
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.
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.