Owen,
I bow to your genius. My experience with reactors has been predicated with experience with ObjectDBX: A programmer must code for every possible event. I learned reactors and ObjectDBX from Tony T. Would you not agree?
If someone knows better please speak up.
Renderman? You seem to be the local expert.
That is kind of you to say (
despite the sarcasm), and quite sad, really... As you're the one touting your super-star tutelage.
Regardless, you've 'put me on the spot'...
For the benefit of future readers of this thread, here is my conclusion from all this: It is NOT necessary to write event handlers for un-needed events in general, but if you need to perform some kind of cleanup or finalizing type action that was initiated in a CommandWillStart event, then you must handle all of CommandCancelled, ComandEnded, and CommandFailed to be sure your cleanup/finalizer code executes.
Because its possible to have different "reactions" to the same event or object, its generally a good idea to understand whats going on with all of them in use, including their possible interactions, even if just to avoid debugging problems later (spaghetti is for lunch, not code ). So its important to plan them from a systemic/overall perspective, rather than the typical encapsulated approach seen in many beginner implementations of LISP code.
The "clean-up" applies in any lisp that changes environmental variables and the user can hit Escape prematurely end the routine.
I don't speak from experience but just the way I understood the reactors to work when I say that the reactors are not fired in a reliable order so other reactors may run & change the environment before yours fires
and therefore you save variables that are not the setting before the event. When you restore the variables you may or may not be in the correct order when CommandCancelled, ComandEnded, and CommandFailed
are fired. If someone knows better please speak up.
In my limited experience, Dgorsman’s sentiment holds true for the customizations incorporated into our deployment(s).
For this reason, I choose to manage multiple reactors (
i.e., Command, DocManager, etc.) from a single project, if not a monolithic file, rather than having each series of Reactor(s), Callback(s), and dependent Sub-Function(s) loaded independently, and running in parallel.
Multiple reactors can function successfully when run at the same time, it all falls back on the code which has been implemented as to the ease with which this will hold true. As Dgorsman has noted already, the latter can easily lead to potential problems, if one does not effectively plan accordingly.
While I have also read that Events are not always going to fire in the order anticipated, it has proven beneficial for our customizations to have each, the
CommandCancelled,
CommandEnded, and
CommandFailed Events call the same Callback function, to both minimize the code necessary for “clean up” following the
CommandWillStart Event, and simplify the task of maintaining the code in the future.
Through this Callback methodology, I prefer to
CONDitionally filter for specific Commands, which also allows for me to execute code in addition to that which is invoked conditionally if desired.
For the most part, our Reactor ‘
framework’ has relatively remained the same, despite additional enhancements being made over the years. As one recent example, adding programmatic
CapsLock functionality for *Text editing Commands.
Within our
CommandWillStart Event, all necessary settings, system variables, etc. are stored either to Global Variables within the ActiveDocument (via
Setq), to the Registry (via
Setenv, or
vl-registry-write), or to Dictionary/XRecord (via
Entmakex, or
vlax-ldata-put) as needed by the code being performed given the Command argument supplied.
If there exists the potential for a Command invocation to change settings prior to the
CommandWillStart Event, then I have neither experienced this personally, nor possess the aptitude to account for such changes given my limited experience.
Perhaps as I continue to grow my skills at developing with .NET technologies, I will have a better understanding in the future.
If others have experienced such undesired behavior, I’d be interested to learn more.
Oh, BTW I made a sh*tload of money yesturday . . ..
Congrats dood; too bad you can't buy manners, talent, or respect... Just saying :kewl:.