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:

[LE3]

not a help at all - but recall seeing this, back on vital lisp too - don't remember if i ever end up doing anything for all my vlisp-reactors code in the past.

glad you still having fun with a-vlisp - cheers!

[Lee Mac]

Cheers Luis 

glad you still having fun with a-vlisp - cheers!

I've tried to overcome the addiction many a time, but LISP still has me hooked 

[CAB]

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 

Can modifying the reactor status be viewed as modifying the object & therefore not allowed while in the callback function? 

[Lee Mac]

Can modifying the reactor status be viewed as modifying the object & therefore not allowed while in the callback function? 

Given the similar behaviour experienced when an owner object resides on a locked layer, that would be a very plausible explanation for this problem Alan. Though, the major underlying issue is that the vlr-remove function reports that the reactor has been removed successfully, instead of throwing an error, and as a result the reactor cannot then be removed by any means other than to close the drawing.

In conclusion:

When using Object Reactors:

• Do not attempt to remove the reactor from within the reactor callback function.

• Verify that all owner objects of an Object Reactor are write enabled before attempting to remove the reactor.

[CAB]

the reactor cannot then be removed by any means other than to close the drawing.

You can delete the object and recreate it.

Good detective work Lee.

[LE3]

In conclusion:

if you got some time, maybe try using this:
http://www.theswamp.org/index.php?topic=9441.msg213956#msg213956
or see inside of:
http://www.theswamp.org/index.php?topic=9441.msg213955#msg213955

[LE3]

In conclusion:

if you got some time, maybe try using this:
http://www.theswamp.org/index.php?topic=9441.msg213956#msg213956
or see inside of:
http://www.theswamp.org/index.php?topic=9441.msg213955#msg213955

just did a quick test nope====does not work: conclusion taken.

[Lee Mac]

the reactor cannot then be removed by any means other than to close the drawing.

You can delete the object and recreate it.

You could, but that wouldn't actually remove the Object Reactor, only set the erase flag on the owner object(s) - they would still be owners to the Object Reactor and the Reactor would still be active in the drawing, to demonstrate:

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  ;; <-------------- Circle is now owner of Object Reactor
5.  
6. Select object:
7. Command:
8. Command: _.erase 1 found ;; <-------------- Circle deleted
9.  
10. Callback Evaluated. ;; <-------------- Callback evaluated on deletion (modification) of circle
11. Command: (vlr-owners object-reactor)
12. (#<VLA-OBJECT IAcadCircle 0e81c314>) ;; <-------------- Circle still owner of Object Reactor after deletion

Good detective work Lee.

Cheers Alan, you too 

[Lee Mac]

In conclusion:

if you got some time, maybe try using this:
http://www.theswamp.org/index.php?topic=9441.msg213956#msg213956
or see inside of:
http://www.theswamp.org/index.php?topic=9441.msg213955#msg213955

just did a quick test nope====does not work: conclusion taken.

Thanks Luis 

[LE3]

played on this a little and maybe thinking a bit too and went to read the help...

Code - Auto/Visual Lisp: [Select]

1. vlr-remove & vlr-remove-all

- will disable the reactor(s) only.

and maybe could it be a good idea to test if it is enabled, before doing any work inside of the callback:

Code - Auto/Visual Lisp: [Select]

1. (defun mycallback  (owner reactor params)
2. (if (vlr-added-p reactor)

so, inside of the callback, one might want to check if the reactor was disabled? first, and that's what has been provided always, a way to disabled the reactors and enabled them for later use, this means that the reactors are still there, unless they are actually removed outside by other means using:

Code - Auto/Visual Lisp: [Select]

1. vlr-owner-remove
2. vlr-data-set

[Lee Mac]

Code - Auto/Visual Lisp: [Select]

1. vlr-remove & vlr-remove-all

- will disable the reactor(s) only.

and maybe could it be a good idea to test if it is enabled, before doing any work inside of the callback:

Code - Auto/Visual Lisp: [Select]

1. (defun mycallback  (owner reactor params)
2. (if (vlr-added-p reactor)

so, inside of the callback, one might want to check if the reactor was disabled?

I would agree, except that in this case vlr-remove / vlr-remove-all don't appear to disable the reactors if called from within the callback function, or if an owner is on a locked layer.

[irneb]

Yep, I think the issue is that object reactors are linked to objects using entity data (in this case a dictionary). And if you want to edit the entity data (i.e. remove the reactor) you need a write lock on that entity. But since the reactor fires, it already has a read-lock since it just read the data of the reactor. Therefore the write-lock cannot be obtained and the edit fails.

You might have to remove the reactor from somewhere else. I.e. when it has finished and the locks are released. Though where to do this I'm not sure - would have been a perfect place for a timer-reactor  :ugly:

[Lee Mac]

You might have to remove the reactor from somewhere else. I.e. when it has finished and the locks are released. Though where to do this I'm not sure...

Reply#7