Topic: :vlr-copied Event Firing Continuously

[Lee Mac]

Yet another Object Reactor anomaly it seems 

Using the following test code to monitor the :vlr-copied event:

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)) "object-reactor"
5.                '((:vlr-copied . 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)

I get the following output to the command-line when I copy the notifying object of the Object Reactor:

Code - Auto/Visual Lisp: [Select]

1. Command: c COPY 1 found
2.  
3. Current settings:  Copy mode = Single
4. Specify base point or [Displacement/mOde/Multiple] <Displacement>: Specify
5. second point or <use first point as displacement>:
6. Callback Evaluated.
7. Callback Evaluated.
8. Callback Evaluated.
9. Callback Evaluated.
10. Callback Evaluated.
11. Callback Evaluated.
12. Callback Evaluated.
13. Callback Evaluated.
14. Callback Evaluated.
15. Callback Evaluated.
16.  
17. ... you get the picture

It seems that the callback for the :vlr-copied event is evaluated continuously whilst the copy command is running.

Before the object is copied (i.e. whilst the user is choosing a point to copy to; or more importantly, whilst the object is 'ghosted' on the screen [perhaps this is registering as a copy operation]), the params argument of the above callback function will return (0), and then (<entity name of copied object>) when the user has chosen a point and the object is copied.

I get the same result for both COPYMODE=0 and COPYMODE=1.

Of course, the simple solution is to test the third argument of the callback function until it returns an entity name, but this seems like a lot of unnecessary processing whilst the user is choosing a copy point and so I'd hopefully like to avoid it.

Can anyone else replicate this behaviour?

[owenwengerd]

That is expected behavior because the original object is copied every time the drag is sampled (unless the object explicitly overrides this behavior).

[irneb]

Yep, the normal copy seems to work similar to what happens when attempting those "dynamic" stuff - like in your Incremental Numbering Suite's Dynamic Mode. So each drag actually makes a copy of the object. I could've thought of a better way by making a move instead, but I guess that's just how it was implemented.

BTW, I've run into this myself. And I've used a deep-clone reactor instead of a copy reactor (though there were other reasons for this as well). See my select result routines here: http://forums.augi.com/showthread.php?81175-select-result-lisp-modification&p=850195&viewfull=1#post850195

[Lee Mac]

That is expected behavior because the original object is copied every time the drag is sampled (unless the object explicitly overrides this behavior).

I figured that might be the explanation, though, I was rather disappointed by the result as I had anticipated similar behaviour to the :vlr-modified event wherein the callback isn't evaluated until the modification has completed.

But, as you have correctly stated: the drag functionality is a continuous copy of the original object, and as I have subsequently discovered, the :vlr-copied is continuously evaluated on all commands that use the drag effect, not only the copy command.

Yep, the normal copy seems to work similar to what happens when attempting those "dynamic" stuff - like in your Incremental Numbering Suite's Dynamic Mode. So each drag actually makes a copy of the object. I could've thought of a better way by making a move instead, but I guess that's just how it was implemented.

BTW, I've run into this myself. And I've used a deep-clone reactor instead of a copy reactor (though there were other reasons for this as well). See my select result routines here: http://forums.augi.com/showthread.php?81175-select-result-lisp-modification&p=850195&viewfull=1#post850195

Thanks Irne, maybe the deep-clone reactor is the way to go with this one - I shall investigate!