Community
Hi all,
I have been avoiding this for a looong time. It is finally here. I need to begin working with reactors. Currently we are using none and I need to address some issues that reactors are likely the only solution.
Just now, I'm asking for advice on Reactors, Dos and Don'ts.
The two reactors that I'll have to tackle first:
- I need a reactor to force save on drawing close. (also nice to have an alert before the save takes place)
- Also, I need a reactor to monitor changes to global / system variable. (for now I'd like to be alerted to changes)
Most of all I have fingers crossed that someone can shed some light in this darkness.
Thank you for any information, but usefull examples are greatly appreciated. 
Reactors only react, they don't actually postpone or cancel the event that call them (like, say, a drawing close). If the save operation takes longer than it takes to close the drawing, then AutoCAD will throw an error as its trying to close a drawing while the save (or supporting) operations are still in progress.
----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
@mid-awe wrote:
Just now, I'm asking for advice on Reactors, dos and don'ts.
The main priority when working with Reactors (and to a degree, when writing any other program) is to account for every possible eventuality that the reactor may encounter - this is especially apparent when working with Object Reactors, since a modification event can be caused by numerous operations.
Furthermore, because Reactors operate autonomously in the background, monitoring for specific events and automatically evaluating the corresponding callback functions, code that is evaluated within a Reactor callback function must be absolutely watertight.
Callback functions which are not completely bulletproof risk crashing or locking up the AutoCAD application, since the callback function is in effect shoe-horning an operation into the standard flow of the application.
As far as dos & don'ts: it is quite well known that you cannot issue command calls from within a Reactor callback function, but you should also avoid any user input from the callback function since, as noted above, this is interupting the standard flow of the application.
@mid-awe wrote:
I need a reactor to force save on drawing close. (also nice to have an alert before the save takes place)
I would agree with the sentiments shared by those above in that if there is an alternative method to accomplishing a certain task that does not involve the use of a Reactor, in 9 out of 10 cases I would likely opt for the alternative (within reason) since Reactors can open a can of worms (or should I say, bugs) and can be a headache to manipulate.
With that said, to provide a simple example demonstrating how to accomplish the task in question, consider the following code:
(defun c:autosave-on ( )
(if (= 'vlr-command-reactor (type autosave:reactor))
(if (vlr-added-p autosave:reactor)
(princ "\nAutosave reactor already running.")
(progn
(vlr-add autosave:reactor)
(princ "\nAutosave reactor enabled.")
)
)
(progn
(setq autosave:reactor
(vlr-command-reactor "autosave-reactor"
'(
(:vlr-commandwillstart . autosave:callback)
)
)
)
(princ "\nAutosave reactor enabled.")
)
)
(princ)
)
(defun c:autosave-off ( )
(if (= 'vlr-command-reactor (type autosave:reactor))
(progn
(vlr-remove autosave:reactor)
(setq autosave:reactor nil)
(princ "\nAutosave reactor disabled.")
)
(princ "\nAutosave reactor not running.")
)
(princ)
)
(defun autosave:callback ( obj arg )
(if
(and
(wcmatch (strcase (car arg)) "QUIT,CLOSE,CLOSEALL")
(= 1 (getvar 'dwgtitled))
)
(vla-save (vla-get-activedocument (vlax-get-acad-object)))
)
(princ)
)
(vl-load-com) (princ)
To test the above application, load the code in the normal way and type autosave-on to enable the Command Reactor. The Command Reactor can be subsequently disabled at any time by typing autosave-off at the command-line.
The Command Reactor will evaluate the callback function for every command issued, before the command operation is initiated. The callback function will then test the name of the issued command against the wildcard pattern specified in the code, and, if a match is found, the callback function will automatically save the drawing.
When monitoring for a drawing close event, you could use either a Drawing Reactor (vlr-dwg-reactor) or Editor Reactor (vlr-editor-reactor), however, the events pertaining to drawing close for these reactors will fire after AutoCAD has issued the prompt for whether or not to save changes to the drawing, hence, a Command Reactor (vlr-command-reactor) must be used as the :vlr-commandwillstart event will be triggered before the 'Save Changes' dialog is issued.
@mid-awe wrote:
Also, I need a reactor to monitor changes to global / system variable. (for now I'd like to be alerted to changes)
For this task you could utilise a vlr-sysvar-reactor, however, note that not all system variables are monitored by this reactor. I don't have a complete reference for those that are, but it would be a simple matter of testing which system variable changes trigger evaluation of the Reactor callback function.
@mid-awe wrote:
Thank you for any information, but useful examples are greatly appreciated.
Since you are looking for some examples, here are a selection of my programs which are driven by Visual LISP Reactors:
Associative Textbox - (also available at the Exchange App Store)
I hope this provides some food for thought.
Lee
You're welcome mid-awe
Though, be careful with the solution that I have provided, the other members raise a good point about it being dangerous to automatically save a drawing without intervention from the user.
Lee
@mid-awe wrote:Why not just alert the drafter if the drawing is read only? If they ignore all notices then it's their time wasted and perhaps they'll pay closer attention next time.
BTW, the sysvar is "WRITESTAT" : 0 means the drawing read-only.
I agree - a simple
(if (zerop (getvar 'writestat))
(alert "Drawing is read-only")
)Placed in the acaddoc.lsp would probably suffice for this.
Though, the reactor route is also pretty simple:
(defun c:roreactoron nil
(if (= 'vlr-command-reactor (type readonly:reactor))
(if (not (vlr-added-p readonly:reactor))
(vlr-add readonly:reactor)
)
(setq readonly:reactor
(vlr-command-reactor nil
'((:vlr-commandwillstart . readonly:callback))
)
)
)
(princ "\nRead Only Reactor enabled.")
(princ)
)
(defun c:roreactoroff nil
(if (= 'vlr-command-reactor (type readonly:reactor))
(vlr-remove readonly:reactor)
)
(setq readonly:reactor nil)
(princ "\nRead Only Reactor disabled.")
(princ)
)
(defun readonly:callback ( obj arg )
(if (zerop (getvar 'writestat))
(alert "WARNING: Drawing is read-only.")
)
(princ)
)
(vl-load-com)
(princ)
The reactor can be enabled or disabled using the roreactoron & roreactoroff commands respectively.
Lee
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")
