Author Topic: Reactor causes fatal error.  (Read 10611 times)

0 Members and 1 Guest are viewing this topic.

owenwengerd

  • Bull Frog
  • Posts: 451
Re: Reactor causes fatal error.
« Reply #15 on: June 21, 2012, 10:11:16 AM »
James, I'm no lisp reactor genius, in fact just the opposite. I do agree that a programmer should write code that works in every scenario (or exits gracefully). It sounded like you were claiming that it's necessary to handle every reactor event, including events that the code doesn't care about. If that's true, I'd like to know why.

jbuzbee

  • Swamp Rat
  • Posts: 851
Re: Reactor causes fatal error.
« Reply #16 on: June 21, 2012, 10:21:21 AM »
Owen,
It's just been my experience: AutoDesk included, I think in 2002, the document event: multiple documents opened required an event to signify which document the reactor should "react" too.  I had Fatal Errors, AutoCad would close, prior to the document argument was included in the call back function.  AutoDesk obviously found that as a problem and corrected it.  Reactors are dangerous if not coded correctly.  That's my experience.

jb
James Buzbee
Windows 8

owenwengerd

  • Bull Frog
  • Posts: 451
Re: Reactor causes fatal error.
« Reply #17 on: June 21, 2012, 11:08:03 AM »
I don't doubt that reactors are dangerous and must be written correctly. Since I have almost no experience with reactors in lisp, I'm hoping to learn something from your experience so that I know how to write them correctly when I do use them. Just to make sure I'm clear and can put this issue to rest, it is NOT necessary to write a handler for all reactor events, correct?

BlackBox

  • King Gator
  • Posts: 3770
Re: Reactor causes fatal error.
« Reply #18 on: June 21, 2012, 11:32:27 AM »
I stand by my original statement:

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.



For consideration... As a simple proof of concept.

... Coding for CommandWillStart Event alone, and intentionally excluding CommandCancelled, ComandEnded, and CommandFailed Events as they are not required for the task being performed within the CommandWillStart Event's Callback function:

Code - Auto/Visual Lisp: [Select]
  1. ;;;--------------------------------------------------------------------;
  2. ;;; Start ReactorFoo function:
  3. (defun ReactorFoo:Start  ()
  4.  
  5.   ;; Command reactors
  6.   (or *ReactorFoo_Command*
  7.       (setq *ReactorFoo_Command*
  8.              (vlr-command-reactor
  9.                nil
  10.                '((:vlr-commandWillStart . CallbackFoo:CommandWillStart)))))
  11.  
  12.   (prompt "\n \n  >>  ReactorFoo Loaded ")
  13.   (princ))
  14. ;;;--------------------------------------------------------------------;
  15. ;;; CallbackFoo:CommandWillStart function:
  16. (defun CallbackFoo:CommandWillStart (rea cmd)
  17.   (alert "You _DO NOT_ have to code for ANY event that can happen")
  18.   (princ))
  19. ;;;--------------------------------------------------------------------;
  20. ;;; Start ReactorFoo function:
  21. (defun c:StartR ()
  22.   (ReactorFoo:Start))
  23. ;;;--------------------------------------------------------------------;
  24. ;;; Stop ReactorFoo function:
  25. (defun c:StopR ()
  26.   (if *ReactorFoo_Command*
  27.     (progn
  28.       (vlr-remove *ReactorFoo_Command*)
  29.       (setq *ReactorFoo_Command* nil)
  30.       (prompt "\n  >>  ReactorFoo stopped ")))
  31.     (princ))
  32. ;;;--------------------------------------------------------------------;
  33. (ReactorFoo:Start)
  34.  





To paraphrase TheMaster... The only Event not being properly reacted to is jbuzbee's ability to concede to having made a mistake... I respectfully ask him (again), to either back up his claims against me, or kindly retract the false allegations.
"How we think determines what we do, and what we do determines what we get."

jbuzbee

  • Swamp Rat
  • Posts: 851
Re: Reactor causes fatal error.
« Reply #19 on: June 21, 2012, 11:40:55 AM »
Really,
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.  However, creating and destroying code is definetely required with reactors: again, look at my code provided.

jb
James Buzbee
Windows 8

Lee Mac

  • Seagull
  • Posts: 12906
  • London, England
Re: Reactor causes fatal error.
« Reply #20 on: June 21, 2012, 12:19:36 PM »

BlackBox

  • King Gator
  • Posts: 3770
Re: Reactor causes fatal error.
« Reply #21 on: June 21, 2012, 12:32:43 PM »

Firstly, I appreciate your concession, James... And I mean that sincerely.

I am no expert, and have much to learn about a great many things; I am here to learn, and help others along the way.

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.

Other than the fact that I explicitly covered this in my original post to this thread, and your stating it here now, where is it exactly that we differ?  :?

I am still utterly perplexed at how you jumped to the conclusion that I 'hack together bad code for [my] own use', or that I somehow need a 'better grasp of reactors [before] giving advice'...? 

Please clarify what source code, or opinion that I (RenderMan) have posted to justify your statements... Otherwise, I fully expect that you will do the honorable thing, and retract your false allegations.
"How we think determines what we do, and what we do determines what we get."

jbuzbee

  • Swamp Rat
  • Posts: 851
Re: Reactor causes fatal error.
« Reply #22 on: June 21, 2012, 12:40:33 PM »
Fine, you win.  I'm going back to my Platform now and see how much money I made yesturday.
James Buzbee
Windows 8

BlackBox

  • King Gator
  • Posts: 3770
Re: Reactor causes fatal error.
« Reply #23 on: June 21, 2012, 12:51:48 PM »
Fine, you win.  I'm going back to my Platform now and see how much money I made yesturday.

... Normality is restored.
"How we think determines what we do, and what we do determines what we get."

owenwengerd

  • Bull Frog
  • Posts: 451
Re: Reactor causes fatal error.
« Reply #24 on: June 21, 2012, 01:24:22 PM »
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.

dgorsman

  • Water Moccasin
  • Posts: 2437
Re: Reactor causes fatal error.
« Reply #25 on: June 21, 2012, 01:35:13 PM »
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.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

CAB

  • Global Moderator
  • Seagull
  • Posts: 10401
Re: Reactor causes fatal error.
« Reply #26 on: June 21, 2012, 02:02:15 PM »
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.
 
 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.
I've reached the age where the happy hour is a nap. (°¿°)
Windows 10 core i7 4790k 4Ghz 32GB GTX 970
Please support this web site.

jbuzbee

  • Swamp Rat
  • Posts: 851
Re: Reactor causes fatal error.
« Reply #27 on: June 21, 2012, 03:23:25 PM »
Quote
If someone knows better please speak up.

Renderman?  You seem to be the local expert.

jb

Oh, BTW I made a sh*tload of money yesturday . . ..
James Buzbee
Windows 8

BlackBox

  • King Gator
  • Posts: 3770
Re: Reactor causes fatal error.
« Reply #28 on: June 21, 2012, 04:33:54 PM »
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'...

Quote
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:.
"How we think determines what we do, and what we do determines what we get."

TimSpangler

  • Water Moccasin
  • Posts: 2010
  • CAD Naked!!
Re: Reactor causes fatal error.
« Reply #29 on: June 21, 2012, 08:12:31 PM »
Congrats dood; too bad you can't buy manners, talent, or respect... Just saying  :kewl:.
:roll:

Mat,

James has been around for as long as I can remember, I have learned a great deal from him over the years, He is VERY talented and VERY respected around here.  He's one whose talent is only over shadowed by his originality, and his out of the box thinking.  We are all here for the same reason.  Inflated ego's and all.  :kewl:
ACA 2015 - Windows 7 Pro
All Comments and Content by TimSpangler, Copyright © 2016