TheSwamp

Code Red => AutoLISP (Vanilla / Visual) => Topic started by: Rustabout on February 20, 2022, 12:43:14 PM

Title: Hundreds (or thousands!) of object reactors existing in a drawing... bad idea?
Post by: Rustabout on February 20, 2022, 12:43:14 PM
Any thoughts?

I've successfully programmed a reactor that more or less mimics the same behavior as a tag in Revit (mine's better actually ;-) ). I'm just wondering if I'm in for a surprise once I have hundreds of these in a single drawing.

I've done a bit of preliminary testing and things seem to be working okay so far.
Title: Re: Hundreds (or thousands!) of object reactors existing in a drawing... bad idea?
Post by: Lee Mac on February 20, 2022, 04:12:54 PM
Why many Object Reactors instead of a single Object Reactor with many owners?
Title: Re: Hundreds (or thousands!) of object reactors existing in a drawing... bad idea?
Post by: Rustabout on February 20, 2022, 05:43:44 PM
Quote
a single Object Reactor with many owners?

I think I meant to say that. I'm only just getting back into using reactors.

A while back I tried this. I may have programmed what I was trying to do incorrectly. I was using extended entity data so that one element could find another when edited (in this case, the reactor would detect the change of a dynamic parameter for length, search out the "tag" and update it, along with other parameters). For whatever reason I went the route of creating a unique object reactor for each object, going as far as to even use the "set" function to create a unique symbol name for each object. I created about 100 objects just to see what would happen and didn't experience any slow down... yet.

After reading your post I'm now thinking that yes I'd only need one reactor. I think my original train of thought was to eliminate one database search from the code or something... (and if I recall I also had an issue with multiple elements changing at once - probably a programming mistake though).

AfraLISP's tutorial results in one reactor per object: https://www.afralisp.net/visual-lisp/tutorials/reactors-part-3.php. I think however that a reactor won't really take up much memory as there really isn't much there (it's more the potential conflicts that would be a concern).
Title: Re: Hundreds (or thousands!) of object reactors existing in a drawing... bad idea?
Post by: kenkrupa on May 17, 2022, 01:43:01 PM
I'm trying to do something similar, in plain AutoCAD - linking a label block with attributes to a special line having xdata storing the handle of the block. Not sure if I'm doing it the same way, as I don't quite understand the issue of "one reactor" vs. hundreds. I have this reactor, which I assign to the line:
(defun xxxx_reactor (obj)
  (vlr-pers (vlr-object-reactor (list obj) nil
              '((:vlr-modified . xxxx_modified))
  ))
)
Seems to work fine, for very many items. Now the problem:
Once an entire plan (1st floor, 2nd floor, roof) is done, that plan wants to be made into a block. At times, that block needs to be exploded for modification, then reblocked. PROBLEM: when the block is exploded, their reactors seem to be gone! Is there some way to deal with this, or am I hosed?!?
Title: Re: Hundreds (or thousands!) of object reactors existing in a drawing... bad idea?
Post by: mhupp on May 17, 2022, 02:48:30 PM
that block needs to be exploded for modification

Why not refedit ?
Title: Re: Hundreds (or thousands!) of object reactors existing in a drawing... bad idea?
Post by: kenkrupa on May 17, 2022, 03:01:07 PM
that block needs to be exploded for modification

Why not refedit ?

Nope - the reactor does not work there either.
Title: Re: Hundreds (or thousands!) of object reactors existing in a drawing... bad idea?
Post by: kenkrupa on May 17, 2022, 07:24:52 PM
Came up with a solution myself. I have a custom routine that does the explode )and another to re-block it). After the explode, I can get a selection set of all items that should have the object reactor (lines with the desired xdata), then re-apply the object reactor to each entity. The explode does not affect the xdata or the label handle, so just redoing the object reactor does the trick. Maybe there's a smarter way, for someone who understands this stuff better than I do, but this works. Finis.