TheSwamp
Code Red => AutoLISP (Vanilla / Visual) => Topic started by: dgorsman on June 19, 2013, 04:58:05 PM
-
Normally in an object reactor, you can *read* properties but for some reason I'm really banging my head on this one. I've got a :vlr-subObjModified reactor connected to a block reference. The callback function executes but for some :realmad: reason even a simple (vla-get-Handle target_obj) on the calling object fails with the "Object open for notification" warning.
(defun testCallback ( target_obj reactor_obj params_list / )
(princ
(strcat
"\n "
(vla-get-Handle target_obj)
)
)
(princ)
)
I'm not setting, changing, modifying *anything*. Handle is read-only property, and even reports from inside the callback function using (vlax-property-available-p target_obj "Handle") as "T".
So why can't I get the handle of the block reference which is firing this reactor?
-
As I understand it, one cannot access a DBObject that is currently-open... For that:
From the Close() override of an ObjectOverrule, you can modify the object.
For more info, please skim this thread (http://www.theswamp.org/index.php?topic=43356.0) for Tony's other comments.
[Edit] - When attempting this in LISP (not .NET), I've only been successful when storing Object(s) during *Modified Events, and processing them within the CommandCancelled/CommandEnded/COmmandFailed Event.
-
Yup, no changes permitted. But I'm not changing anything, and have no intention of doing so. And here's the kicker: when called from a :vlr-modified reaction, the handle *can* be read from the target argument.
-
But I'm not changing anything,
To my knowledge, Visual Lisp doesn't do proper code etiquite of elevating permissions from read to readwrite as you should do in .net. All VisualLisp access is readwrite.
Is it possible to cache the object and wait for the command to end?
-
That's exactly what I suggested above... To, on CommandWillStart, monitor for the ObjectModified event to store the modified Objects to global variable, then process Objects in CommandCancelled, CommandEnded, or CommandFailed.
It's the only way to access Objects this way, due to the inability to access and Object that is already opened... Unless that Object is one of the parameters of the Callback parameters themselves.
-
Still not quite buying it. I can access the handle, owner ID, and other read-only properties on :vlr-Modified reactors. The block reference object itself is the first argument of the callback function. THe attribute being modified is passed as an entity (yah, not a vla-object) in the params_list and even then, trying to work back up through the owner ID still fails. I can process *that* to my hearts content, but I really need that owning block reference handle/ID. There's no command involved to hook for a post-process function, either.
I'll just have to replace the :vlr-subObjModified on the block reference with a :vlr-Modified for each of the attribute references. PITA, since I have to process the OwnerID to the get the owning block reference, but at least it works.
-
There's no command involved to hook for a post-process function, either.
I have the same problem with my .NET plug-in linked above, as I was using Properties Palette to modify entities... Tony pointed me toward one of his extensions for that.
Glad you at least found one way to get it sorted.