(defun np:test (reactor callbackdata / )
(setq abc 123)
)
(if (not np:reactor1)
(setq np:reactor1
(vlr-command-reactor nil '((:vlr-commandwillstart . np:test)))
)
)
;;; Command Will Start ;
(defun kb:CommandWillStart (calling-reactor commands / lname)
(cond ((member (car commands)
(list "MTEXT" "-MTEXT" "DTEXT" "TEXT" "-TEXT" "LEADER" "QLEADER" "MLEADER"
)
)
(setq lname (AECGENERATELAYERKEY "ANNOBJ"))
)
((member (car commands)
(list "DIMLINEAR" "DIMALIGNED" "DIMBASELINE" "DIMCONTINUE" "DIMDIAMETER"
"DIMANGULAR" "DIMRADIUS" "DIMORDINATE" "QDIM"
)
)
(setq lname (AECGENERATELAYERKEY "DIMLINE"))
)
((member (car commands) (list "VPORTS" "-VPORTS"))
(setq lname (AECGENERATELAYERKEY "ANNDTOBJ"))
)
((member (car commands) (list "IMAGE" "-IMAGE")) ;"-XREF" "XREF" "XATTACH"
(setq lname "XREF")
)
)
(if lname
(kb:setclayer lname T)
)
)
;;; Command Ended ;
(defun kb:CommandEnded (calling-reactor commands / dwgdimscale doc)
(cond ((member (car commands)
(list "MTEXT" "-MTEXT" "DTEXT" "TEXT" "-TEXT"
"LEADER" "QLEADER" "MLEADER" "DIMLINEAR" "DIMALIGNED" "DIMBASELINE"
"DIMCONTINUE" "DIMDIAMETER" "DIMANGULAR" "DIMRADIUS" "DIMORDINATE"
"QDIM" "MVIEW" "VPORTS" "-VPORTS" "IMAGE" "-IMAGE"
)
)
(kb:resetclayer)
)
((member (car commands) (list "CLOSE" "QUIT"))
(if (dcl_Form_IsActive ADT_ADTPalette)
(progn (dcl_form_Close ADT_ADTPalette))
)
(if (dcl_Form_IsActive DetailManager_DMPalette)
(progn (dcl_form_Close DetailManager_DMPalette))
)
)
((member (car commands) (list "PASTECLIP" "PURGE" "BLOCK" "INSERT" "-PURGE" "-BLOCK" "-INSERT"))
(if (dcl_Form_IsActive Blocks_BlockManager)
(c:Blocks_BlockManager_OnInitialize)
)
(if (dcl_Form_IsActive ADT_ADTPalette)
(c:ADT_ADTPalette_OnInitialize)
)
)
)
)
;;; Command Cancelled ;
(defun kb:CommandCancelled (calling-reactor commands /)
(cond ((member (car commands)
(list "MTEXT" "-MTEXT" "DTEXT" "TEXT" "-TEXT" "LEADER" "QLEADER" "MLEADER"
"DIMLINEAR" "DIMALIGNED" "DIMBASELINE" "DIMCONTINUE" "DIMDIAMETER"
"DIMANGULAR" "DIMRADIUS" "DIMORDINATE" "QDIM" "MVIEW" "VPORTS"
"-VPORTS" "IMAGE" "-IMAGE"
)
)
(kb:resetclayer)
)
)
)
;;; Construct the Command Reactor ;
(defun kb::ConstructCommandReactor (/)
(if (= (type *kbCommandReactor*) 'VLR-Command-Reactor)
(progn (vlr-remove *kbCommandReactor*) (setq *kbCommandReactor* nil))
)
(if (/= (type *kbCommandReactor*) 'VLR-Command-Reactor)
(setq *kbCommandReactor*
(VLR-Command-Reactor
"kbTools Command Reactor" ; Data associated with the editor reactor
;; call backs
'
((:VLR-commandWillStart . kb:CommandWillStart)
(:VLR-commandEnded . kb:CommandEnded)
(:VLR-commandCancelled . kb:CommandCancelled)
)
) ;_ end of vlr-editor-reactor
)
)
(if (not (vlr-added-p *kbCommandReactor*))
(progn (vlr-add *kbCommandReactor*)
(vlr-set-notification *kbCommandReactor* 'active-document-only)
)
)
;added 09.26.2003
(princ)
)
;;; load reactors ;
(if kb::ConstructCommandReactor
(kb::ConstructCommandReactor)
)
OK, I'm fairly new to the world of reactors and have run into a problem which I'm hoping somebody can help me with.
<snip>
Is there anybody out there who can confirm whether they get the same errors as me or whether I am doing something fundamentally wrong in the way I am handling reactors?
Command: mvsetup
Initializing...
Enable paper space? [No/Yes] <Y>: *Cancel*
Command: !abc
123
You have to code for ANY event that can happen: CommandStart, CommandEnded, CommandCancelled.
...I've tested the code you posted, and while I would not code it that way personally, the code tests fine using Civil 3D 2011:Code: [Select]Command: mvsetup
Initializing...
Enable paper space? [No/Yes] <Y>: *Cancel*
Command: !abc
123
Full explanation here (http://docs.autodesk.com/ACDMAC/2013/ENU/filesALRMac/GUID-43D3D099-D59E-4503-A355-FB5A1364CA22.htm)
This statement is incorrect... One need only code for the Events which one intends to monitor, or react to, and _not_ "ANY event that can happen."
You have to code for ANY event that can happen: CommandStart, CommandEnded, CommandCancelled.
This statement is incorrect... One need only code for the Events which one intends to monitor, or react to, and _not_ "ANY event that can happen."
However, as a minimum standard (IMO)... A responsible developer will implement CommandCancelled, CommandEnded, and CommandFailed Event Callback(s) when modifying the end-user's environment (i.e., settings, sysvars, etc.) via the CommandWillStart Event.
While a best practice, these are _not_ necessary for the CommandWillStart Callback to perform.@ mr_nick -
You may find this post (http://www.theswamp.org/index.php?topic=41861.msg469921#msg469921) to be helpful; (if you scroll down a bit) it contains a few different Command Reactor examples, with some extra goodies as an attachment.
Note - This is not the only way to code a Command Reactor, and the dependent Callback functions. This is only intended to be an example. I'm sure there are better, smarter, faster ways of doing this.
Any good developer will: Reactors are dangerous. It's all well and good for you to hack together bad code for your own use, but until you have a better grasp of reactors you should refrain from giving advice.
Just sayin.
You have to code for ANY event that can happen: CommandStart, CommandEnded, CommandCancelled.
This statement is incorrect... One need only code for the Events which one intends to monitor, or react to, and _not_ "ANY event that can happen."
However, as a minimum standard (IMO)... A responsible developer will implement CommandCancelled, CommandEnded, and CommandFailed Event Callback(s) when modifying the end-user's environment (i.e., settings, sysvars, etc.) via the CommandWillStart Event.
While a best practice, these are _not_ necessary for the CommandWillStart Callback to perform.
The example code I provided, if you (RenderMan) would have examined, clearly shows that if your changing any state of the drawing one must code for the event if the command was cancelled. I will concede that if the routine does not require a change with command ended that could be excluded.
Fine, you win. I'm going back to my Platform now and see how much money I made yesturday.
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.The "clean-up" applies in any lisp that changes environmental variables and the user can hit Escape prematurely end the routine.
If someone knows better please speak up.
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.
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.
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:.:roll:
Have you tested your reactor with a LINE command and hit ESC part way through. Then close the drawing.
A word of warning! Did you notice how I used ActiveX statements and functions to "Save" and "SaveAs". You cannot use interactive functions from within a reactor 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, ensel, and getkword, as well as "selection set" operations and the command function.
Command is NOT being used within the reactor. Command-s is being used in a drawing which has a reactor running. Doesn't matter what the reactor is actually doing - just it's actual presence is enough to cause the crash.
Hence loading RenderMans or jbuzbees code samples and then using command-s you will crash AutoCAD.
jeez you guy's can't be this stupid. You CAN'T use ANY form of COMMAND in a reactor.
Stop.
Still the same thing.
Indeed you cannot any form of command within the callback function of a reactor.
I believe that both James and I said this?Quote from: jbuzbeeYou CAN'T use ANY form of COMMAND in a reactor.Quote from: TimSpanglerI remember reading somewhere (not being a master of reactors my self) that you can not use "command" in a reactor?
But from what I understand of this thread, the OP is remarking on the fact that AutoCAD will crash when the new command-s function is used independently of the reactor callback function whilst a reactor is running.
Just commenting because the title clearly says "Reactor causes fatal error". Just trying to get to the bottom of the issue. If you are running the mvsetup from the callback then it is being used IN a reactor, YES?
Command is NOT being used within the reactor. Command-s is being used in a drawing which has a reactor running. Doesn't matter what the reactor is actually doing - just it's actual presence is enough to cause the crash.
Still the same thing.
I'm running 2010 so I can't test this as "command-s" doesn't exist.
So if you open the mvsetup.lsp (save a copy of the original) and replace "command-s" with "command" does it solve the problem?
If I edit the MVSETUP file to use command rather than command-s then no fatal error is encountered.
Thanks :lol:
So there was no ? in this post, just an observation? information? :wink:
It just gost lost among all the posturing.