Author Topic: check if an object already has a reactor connected  (Read 2324 times)

0 Members and 1 Guest are viewing this topic.

Lupo76

  • Bull Frog
  • Posts: 343
check if an object already has a reactor connected
« on: March 30, 2012, 12:17:52 PM »
Hello everyone,
I apologize for my bad English
how can I check whether an object has a reactor connected?

Let me explain:
I wrote the following code:
 
Code: [Select]
(defun c:ass (/ ogg collegaReactor)
  (setq ogg (car (entsel)))
 
  (setq collegaReactor
    (vlr-object-reactor (list (vlax-ename->vla-object ogg)) "NOMEAPP"
      '(
        (:vlr-modified . testedit)
        (:vlr-objectClosed . endedit)
       )
    )
  )
)


(defun testedit (notifier-object reactor-object parameter-list / ogg collegaReactor)
  (alert "testedit")
)

(defun endedit (notifier-object reactor-object parameter-list / ogg collegaReactor)
  (alert "endedit")
)

 

If I start two or three or more times the "c:ass" and select the same object, when I changethe "alert" appear several times.
You can work around this problem?
 

Lee Mac

  • Seagull
  • Posts: 12910
  • London, England
Re: check if an object already has a reactor connected
« Reply #1 on: March 30, 2012, 12:41:18 PM »
Check the objects against the list returned by the vlr-owners function

Lupo76

  • Bull Frog
  • Posts: 343
Re: check if an object already has a reactor connected
« Reply #2 on: March 31, 2012, 02:49:54 AM »
Hello Lee,
thanks for your answer
I read the online help function on vlr-owners.

Unfortunately I can not figure out how to use it in my context.
I did not understand what should the value of??? :|

(vlr-owners???)

Perhaps the question is trivial for you, but I did not for me.
I used the reactors intensively but without understanding them thoroughly :oops:

Lee Mac

  • Seagull
  • Posts: 12910
  • London, England
Re: check if an object already has a reactor connected
« Reply #3 on: March 31, 2012, 05:41:23 AM »
Consider the following code:

Code - Auto/Visual Lisp: [Select]
  1. (defun c:ass ( / allowners ent objectreactor )
  2.     (setq allowners
  3.         (mapcar 'vla-get-handle
  4.             (apply 'append
  5.                 (mapcar 'vlr-owners
  6.                     (cdar (vlr-reactors :vlr-object-reactor))
  7.                 )
  8.             )
  9.         )
  10.     )
  11.     (while
  12.         (progn (setvar 'ERRNO 0) (setq ent (car (entsel)))
  13.             (cond
  14.                 (   (= 7 (getvar 'ERRNO))
  15.                     (princ "\nMissed, try again.")
  16.                 )
  17.                 (   (eq 'ENAME (type ent))
  18.                     (if (member (cdr (assoc 5 (entget ent))) allowners)
  19.                         (princ "\nObject is already an owner of a Reactor.")
  20.                     )
  21.                 )
  22.             )
  23.         )
  24.     )
  25.     (if ent
  26.         (setq objectreactor
  27.             (vlr-object-reactor (list (vlax-ename->vla-object ent)) "NOMEAPP"
  28.                '(
  29.                     (:vlr-modified . testedit)
  30.                     (:vlr-objectClosed . endedit)
  31.                 )
  32.             )
  33.         )
  34.     )
  35.     (princ)
  36. )
  37.  
  38. (defun testedit ( notifier-object reactor-object parameter-list )
  39.     (alert "testedit")
  40.     (princ)
  41. )
  42.  
  43. (defun endedit ( notifier-object reactor-object parameter-list  )
  44.     (alert "endedit")
  45.     (princ)
  46. )

As an aside: since Reactors are considered a more advanced area of Visual LISP, I would strongly suggest that you have a good grasp of AutoLISP / Visual LISP before working with them. Without solid coding, reactors will have you pulling your hair out before too long.

CAB

  • Global Moderator
  • Seagull
  • Posts: 10401
Re: check if an object already has a reactor connected
« Reply #4 on: March 31, 2012, 06:59:10 AM »
As an aside: since Reactors are considered a more advanced area of Visual LISP, I would strongly suggest that you have a good grasp of AutoLISP / Visual LISP before working with them. Without solid coding, reactors will have you pulling your hair out before too long.


Ditto  8-)
Defiantly an advanced area for programing.
I've reached the age where the happy hour is a nap. ()
Windows 10 core i7 4790k 4Ghz 32GB GTX 970
Please support this web site.

Lupo76

  • Bull Frog
  • Posts: 343
Re: check if an object already has a reactor connected
« Reply #5 on: March 31, 2012, 10:54:32 AM »
Ok now everything is clear.  :ugly:
I missed this part:
Code: [Select]
    (setq allowners
        (mapcar 'vla-get-handle
            (apply 'append
                (mapcar 'vlr-owners
                    (cdar (vlr-reactors :vlr-object-reactor))
                )
            )
        )
    )

thank you!  :-)

I am aware that the reactors are an advanced programming lisp / vlisp, but sooner or later, considering their power, I have to start using them.
I am aware that I have to do many tests, before arriving at an optimum result.
I hope in your help for this.  :-D

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: check if an object already has a reactor connected
« Reply #6 on: March 31, 2012, 11:05:04 AM »
I concur, with reactors (especially object reactors) make sure your code runs without ANY problems. The multiple attachments you've come across is probably one of the more benign that you might run into. Some may even crash acad, or (pray this never happens) loss of data. So before starting to use these things (even if you're the most experienced lisper on the planet) I'd advise to test and test and test ... and then test some more ... and just to be on the safe side test again ... and then again.

These things tend to have a mind of their own if you don't look out (or at least they appear to), it's a situation of "With great power comes great resposibility" ... it's just that in this case it reads more like: "Great capability seeds propensity for error".
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.