Topic: vlr-remove not removing Object Reactor inside Callback Function

[Lee Mac]

Having spent some time pulling my hair out whilst trying to figure out why my reactor callback functions were continuously being evaluated, I believe I have isolated the issue to a possible bug with the vlr-remove function wherein object reactors are not actually removed by this function.

I have put together the following simple code to demonstrate the issue I am experiencing:

Code - Auto/Visual Lisp: [Select]

1. (defun c:addreactor ( / en )
2.     (if (setq en (car (entsel)))
3.         (setq object-reactor
4.             (vlr-object-reactor (list (vlax-ename->vla-object en)) "My Object Reactor"
5.                '((:vlr-modified . mycallback))
6.             )
7.         )
8.     )
9.     (princ)
10. )
11.  
12. (defun mycallback ( owner reactor params )
13.     (princ "\nCallback Evaluated.")
14.     (print (vlr-remove reactor))
15.     (princ)
16. )
17. (vl-load-com)
18. (vlr-remove-all :vlr-object-reactor)
19. (princ)

Steps to recreate problem:

• Create a circle in the drawing (or any object in fact)
• Run the above program 'addreactor' and click on the created circle
• Move the circle

Now, at this point the circle has been modified and so the reactor callback function will be evaluated, printing the message 'Callback Evaluated' at the command-line.

Within the callback function the calling object reactor is removed using vlr-remove, and hence the callback function should no longer be evaluated if the circle is modified again.

However, I find the following unexpected result:

Code - Auto/Visual Lisp: [Select]

1. Command: _circle Specify center point for circle or [3P/2P/Ttr (tan tan radius)]:
2. Specify radius of circle or [Diameter]:
3. Command:
4. Command: addreactor
5.  
6. Select object:
7. Command:
8. Command:
9. Command: m MOVE 1 found
10.  
11. Specify base point or [Displacement] <Displacement>:
12. Specify second point or <use first point as displacement>:
13. Callback Evaluated.  ;; <-------------- Callback evaluated as expected, Reactor should now be removed.
14. #<VLR-Object-Reactor> ;; <-------------- vlr-remove returns Reactor Object, indicating removal is successful
15. Command:
16. Command: m MOVE 1 found
17.  
18. Specify base point or [Displacement] <Displacement>:
19. Specify second point or <use first point as displacement>:
20. Callback Evaluated.  ;; <--------------  Callback still being evaluated even after reactor is removed.
21. nil ;; <-------------- vlr-remove returning nil as reactor has already been removed.

This is even weirder:

Code - Auto/Visual Lisp: [Select]

1. Command: _circle Specify center point for circle or [3P/2P/Ttr (tan tan radius)]:
2. Specify radius of circle or [Diameter]:
3. Command:
4. Command: addreactor
5.  
6. Select object:
7. Command:
8. Command:
9. Command: m MOVE 1 found
10.  
11. Specify base point or [Displacement] <Displacement>:
12. Specify second point or <use first point as displacement>:
13. Callback Evaluated. ;; <--------------  Reactor should now be removed.
14. #<VLR-Object-Reactor> ;; <-------------- vlr-remove returns Reactor object, indicating removal is successful
15. Command:
16. Command: (vlr-added-p object-reactor)
17. nil ;; <-------------- Verifying that Reactor has been removed
18.  
19. Command: (vlr-reactors)
20. nil ;; <-------------- Verifying that no Reactors are running
21.  
22. Command:
23. Command: m MOVE 1 found
24.  
25. Specify base point or [Displacement] <Displacement>:
26. Specify second point or <use first point as displacement>:
27. Callback Evaluated. ;; <-------------- Yet callback STILL being evaluated... WTF
28. nil

Can any of you guys replicate this behaviour? Or maybe spot a mistake in my method?

[CAB]

Same here in ACAD2006.
Using this:

Code: [Select]

(defun c:removeowner (/ en)
  (if (and object-reactor (setq en (car (entsel))))
    (print (vlr-owner-remove object-reactor (vlax-ename->vla-object en)))
  )
  (princ)
)
It works only if the reactor has not been fired, if it has been fired the circle is returned
but the reactor continues to fire.

[CAB]

Adding back trace yields nothing useful.
** STRETCH **
Specify stretch point or [Base point/Copy/Undo/eXit]: Backtrace:
[0.18] (VL-BT)
[1.14] (MYCALLBACK #<VLA-OBJECT IAcadCircle 0b8b3a64> #<VLR-Object-Reactor> nil) LAP+7
:CALLBACK-ENTRY.6 (:CALLBACK-ENTRY)
:REACTOR-CALLBACK.3 :REACTOR-CALLBACK

Callback Evaluated.
nil


This is no help
Command: (vlr-remove-all :vlr-object-reactor)
nil

[Lee Mac]

Thank you very much for your time spent testing Alan, I appreciate your assistance 

After some more experimentation on my side, I have further isolated the problem and have found that it only occurs when removing the object reactor from within its callback function.

I tried using the following callback function instead :

Code - Auto/Visual Lisp: [Select]

1. (defun mycallback ( owner reactor params )
2.    (princ "\nCallback Evaluated.")
3.    (princ)
4. )

And here are is my results from the command-line:

Code - Auto/Visual Lisp: [Select]

1. Command: _circle
2. Specify center point for circle or [3P/2P/Ttr (tan tan radius)]:
3. Specify radius of circle or [Diameter]:
4. Command: addreactor
5.  
6. Select object:
7. Command:
8. Command:
9. Command: m MOVE 1 found
10.  
11. Specify base point or [Displacement] <Displacement>:
12. Specify second point or <use first point as displacement>:
13. Callback Evaluated. ;; <-------------- Callback evaluated
14. Command: (vlr-remove object-reactor) ;; <-------------- Reactor now removed 'manually'
15. #<VLR-Object-Reactor> ;; <-------------- Reactor removed successfully
16.  
17. Command:
18. Command: m MOVE 1 found
19.  
20. Specify base point or [Displacement] <Displacement>:
21. Specify second point or <use first point as displacement>:
22. ;; <-------------- Callback not evaluated!

So in conclusion at this point:

If vlr-remove is evaluated from within the callback function, the Reactor is 'registered' as being removed (i.e. the VLA Reactor Object is returned and the vlr-remove* functions no longer have any effect) but the Reactor isn't actually removed since the callback is still evaluated.
 

[Lee Mac]

After some testing with a Command Reactor, I have found that this problem only appears to apply to removing Object Reactors from within their own callback functions.

Using this code:

Code - Auto/Visual Lisp: [Select]

1. (defun c:addreactor ( )
2.     (setq com (vlr-command-reactor "My Command Reactor" '((:vlr-commandended . mycallback))))
3.     (princ)
4. )
5.  
6. (defun mycallback ( reactor params )
7.     (princ "\nCallback Evaluated.")
8.     (vlr-remove reactor)
9.     (princ)
10. )
11. (vl-load-com)
12. (vlr-remove-all :vlr-command-reactor)
13. (princ)

Here are my results:

Code - Auto/Visual Lisp: [Select]

1. Command: addreactor  ;; <-------------- Command Reactor added.
2. Command:
3. Command:
4. Command: m MOVE 1 found
5.  
6. Specify base point or [Displacement] <Displacement>:
7. Specify second point or <use first point as displacement>:
8. Callback Evaluated. ;; <-------------- Callback evaluated, Command Reactor removed.
9. Command:
10. Command: m MOVE 1 found
11.  
12. Specify base point or [Displacement] <Displacement>:
13. Specify second point or <use first point as displacement>:
14. ;; <-------------- Callback NOT evaluated

[Lee Mac]

Now that I have understood that one cannot disable an Object Reactor from within its own callback function, I have managed to implement a working solution in my application by disabling the Object Reactor from another callback function.

I would like to thank the community for their time on this thread, especially CAB's contribution, and I hope that the thread serves as a guide and explanation for others encountering this issue.

Thanks 

Lee

[CAB]

Good detective work Lee.
But how can you combine reactors or chain them and be sure which is triggered first?
I'm assuming that is how you did it.
(Rather slow here on the weekends  )

[Lee Mac]

Good detective work Lee.

Thanks Alan 

But how can you combine reactors or chain them and be sure which is triggered first?
I'm assuming that is how you did it.
(Rather slow here on the weekends  )

I used a combination of an Object Reactor triggered by the :vlr-modified event and a Command Reactor triggered on the :vlr-commandended event, and disabled the Object Reactor from within the callback function of the Command Reactor (instead of disabling it from the callback function of the Object Reactor, which sparked this thread topic) before performing the necessary modifications to the owner object and re-enabling the Object Reactor (again from the callback function of the Command Reactor).

[Lee Mac]

New Development...

I've also just discovered that vlr-remove will fail to remove an Object Reactor if any one of it's owners resides on an Locked Layer.

Steps to recreate this condition:

Code - Auto/Visual Lisp: [Select]

1. (defun c:addreactor ( / en )
2.    (if (setq en (car (entsel)))
3.        (setq object-reactor
4.            (vlr-object-reactor (list (vlax-ename->vla-object en)) "My Object Reactor"
5.               '((:vlr-modified . mycallback))
6.            )
7.        )
8.    )
9.    (princ)
10. )
11.  
12. (defun mycallback ( owner reactor params )
13.    (princ "\nCallback Evaluated.")
14.    (princ)
15. )
16. (vl-load-com)
17. (vlr-remove-all :vlr-object-reactor)
18. (princ)

• Create a circle (or any object) in the drawing
• Run the above code and select the circle
• Lock the circle's layer
• Type at the command-line (vlr-remove object-reactor)
• Unlock the circle's layer and move the circle

Here are my results:

Code - Auto/Visual Lisp: [Select]

1. Command: _circle
2. Specify center point for circle or [3P/2P/Ttr (tan tan radius)]:
3. Specify radius of circle or [Diameter]:
4. Command: addreactor
5.  
6. Select object:
7. Command:
8.  
9. ;; <--------- Layer Locked --------->
10.  
11. Command: (vlr-remove object-reactor) ;; <-------------- Reactor removed 'manually'
12. #<VLR-Object-Reactor> ;; <-------------- Indicating reactor has been removed successfully.
13.  
14. ;; <--------- Layer Unlocked --------->
15.  
16. Command:
17. Command: m MOVE 1 found
18.  
19. Specify base point or [Displacement] <Displacement>:
20. Specify second point or <use first point as displacement>:
21. Callback Evaluated. ;; <--------------  Callback still being evaluated after reactor is removed.

Note that the Object Reactor is not removed even after using vlr-remove 'manually' at the command-line.

The Solution:

Use vlax-write-enabled-p to check whether owner objects are write enabled before attempting to remove an Object Reactor.

[CAB]

One solution I pondered was to delete the object which kills the reactor.
Then recreate it, not sure you can do all this from within the call back reactor.
No time this morning to test it. Getting ready for the coming weather.

[Lee Mac]

One solution I pondered was to delete the object which kills the reactor.
Then recreate it, not sure you can do all this from within the call back reactor.

Thank you for the suggestion, but this wouldn't be possible I'm afraid since the owner object is notifying the Object Reactor and hence cannot be deleted whilst notifying.

Given that I now understand the somewhat stricter rules that apply to manipulating Object Reactors over other Reactors, I know where I stand and can write my applications accordingly to account for this behaviour. Coding applications around known bugs can be annoying, but certainly far less frustrating than not knowing the bug exists and scratching your head as to why things are crashing...

No time this morning to test it. Getting ready for the coming weather.

Ah yes, Isaac has been covered in the news over here too - I wish you all the best and hope the storm passes through safely.

[PKENEWELL]

FYI - I get the same Behavior in AutoCAD Mechnical 2013. I don't know what version you are using, but it looks like Autodesk has not fixed it yet. 

Code - Auto/Visual Lisp: [Select]

1. Command: ADDREACTOR
2. Select object:
3. Command:
4. Command:
5. Command:
6. ** STRETCH **
7. Specify stretch point or [Base point/Copy/Undo/eXit]:
8. Callback Evaluated.
9. #<VLR-Object-Reactor>
10. Command:
11. ** STRETCH **
12. Specify stretch point or [Base point/Copy/Undo/eXit]:
13. Callback Evaluated.
14. nil
15. Command: (vl-load-com)
16. Command: (vlr-remove-all :vlr-object-reactor)
17. nil
18. Command:
19. ** STRETCH **
20. Specify stretch point or [Base point/Copy/Undo/eXit]:
21. Callback Evaluated.
22. nil
23.  

Code - Auto/Visual Lisp: [Select]

1. Command: (defun mycallback ( owner reactor params )
2. (_>    (princ "\nCallback Evaluated.")
3. (_>    (princ)
4. (_> )
5. MYCALLBACK
6. Command: CI
7. CIRCLE
8. Specify center point for circle or [3P/2P/Ttr (tan tan radius)]:
9. Specify radius of circle or [Diameter] <1.9370>:
10. Command: addreactor
11. Select object:
12. Command:
13. ** STRETCH **
14. Specify stretch point or [Base point/Copy/Undo/eXit]:
15. Callback Evaluated.
16. Command: *Cancel*
17. Command: (vl-load-com)
18. Command: (vlr-remove-all :vlr-object-reactor)
19. ((:VLR-Object-Reactor #<VLR-Object-Reactor>))
20. Command:
21. Command:
22. ** STRETCH **
23. Specify stretch point or [Base point/Copy/Undo/eXit]:
24. Command:
25.  

[Lee Mac]

Thank you for your time testing it Phil, your results in 2013 and CAB's results in 2006 confirm my suspicions that these are indeed bugs present in most, if not all, versions of AutoCAD and its derivative programs.

Since LISP is no longer in development I very much doubt these issues will be fixed any time soon, though, at least we are now aware of them and can code around them.

Thanks 

[PKENEWELL]

Thank you for your time testing it Phil, your results in 2013 and CAB's results in 2006 confirm my suspicions that these are indeed bugs present in most, if not all, versions of AutoCAD and its derivative programs.

Since LISP is no longer in development I very much doubt these issues will be fixed any time soon, though, at least we are now aware of them and can code around them.

Thanks 

Very True. Thanks to you as well for discovering the issue. Saves the rest of us the frustration of discovering it ourselves.   

[Lee Mac]

Saves the rest of us the frustration of discovering it ourselves.   

Believe me... there was frustration in abundance before this thread was started  :ugly: