As I mentioned at the start of this chapter, Reactors demand careful attention to planning and consderation for performance and stability. The following guidelines are provided in the AutoCAD online Help documentation and are very good points to consider.
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.
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.
WARNING: A VLX may run in a separate‐namespace from the document it is loaded from, but it is still associated with that originating document and cannot manipulate objects in other documents.
active. By default, a reactor callback function will execute only if a notification event occurs when the document it was defined in is the active document. You can alter this behavior using the vlr-set- notification function.
To specify that a reactor should execute its callback function even if the document it was defined in is not active (for example, if an application in another namespace triggers an event), issue the following function call:
(vlr-set-notification reactor-object 'all-documents)
This can be useful to notify all instances of your application (that is, if not a separate namespace VLX application propagated to all sessions) that an event occurred in one of the sessions.
To modify a reactor so it only executes its callback function if an event occurs when the document it was defined in is active, issue the following:
(vlr-set-notification reactor-object 'active-document-only)
The vlr-set-notification function returns the specified reactor object. For example, the following sequence of commands defines a reactor and sets it to respond to events whether or not its associated document is active:
_$ (setq circleReactor (vlr-object-reactor (list myCircle) "Circle Reactor" '((:vlr-modified . print-radius))))
#<VLR-Object-Reactor>
_$ (vlr-set-notification circleReactor 'all-documents) #<VLR-Object-Reactor>
To determine the notification setting of a reactor, use the vlr-notification function. For example:
_$ (vlr-notification circleReactor) all-documents
The vlr-set-notification function affects only the specified reactor. All reactors are created with the default notification set to active‐document‐only.
WARNING: If you choose to set a reactor to execute its callback function even if triggered when its document is not active, the callback function should do nothing other than set and read AutoLISP system variables. Performing other types of actions may cause AutoCAD to become unstable or crash!
Note that VBA provides no equivalent to vlr-CommandCancelled, which means that only through Vlisp can you handle a user pressing ESC during a command being managed by a command reactor.
Probably the most significant feature provided by Visual LISP is the capability to build and manage applications. In this context, we are really talking about VLX applications, but you could consider FAS output to be applications as well. The building of Visual LISP applications is closely tied to the use of Projects, but they are not inseparable.