Author Topic: Hundreds (or thousands!) of object reactors existing in a drawing... bad idea?  (Read 1111 times)

0 Members and 1 Guest are viewing this topic.

Rustabout

  • Newt
  • Posts: 135
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.

Lee Mac

  • Seagull
  • Posts: 12906
  • London, England
Why many Object Reactors instead of a single Object Reactor with many owners?

Rustabout

  • Newt
  • Posts: 135
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).

kenkrupa

  • Newt
  • Posts: 84
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?!?

mhupp

  • Bull Frog
  • Posts: 250
that block needs to be exploded for modification

Why not refedit ?

kenkrupa

  • Newt
  • Posts: 84
that block needs to be exploded for modification

Why not refedit ?

Nope - the reactor does not work there either.

kenkrupa

  • Newt
  • Posts: 84
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.