Layer with elevation property

Dear friends.

Is it possible, with a routine Autolisp, assign a layer to the property elevation?

I know that we can at any time of work to change the elevation property

or even the Z value of UCS, but would interestingly, this property could

be aggregated so that a layer. when that layer was active elevation assume the set value.

In this case it would be possible to have multiple layers

with different Elevations. Could be interested in some 3D work.

you could write a routine that uses a reactor to change the elevation system variable whenever a command is called and that particular layer is current, as to setting it as a layer property, I do not believe that is possible.

I would answer "no". From your AutoCAD Help file.

Elevation

"Stores the current elevation of new objects relative to the current UCS."

Notice the word "objects"?

Thanks for the replies.

Ok Indeed it is. What I wanted was that the layer to activate the

UCS parameter Z was changed to a value set in advance and

entities created in this layer will have all their elevation.

To summarize the idea, the elevation would be one more property of the layer, such as color, line type, line width, etc..

Are valuse for Z always going to be constant or variable?

Are valuse for Z always going to be constant or variable?

I suppose you "could" add the data onto the layer as ldata/xdata/xrecord. But then you need to have a separate lisp so the user can setup these "layer-elevations" through it. And then you need to step through all entities modifying those on the layer(s) to their specified elevation. And then as ccowgill suggests use a reactor to set the current elevation according to the current layer's setting - so all new entities also follow suit.

That's the "big" question isn't it?

 

I suppose you "could" add the data onto the layer as ldata/xdata/xrecord. But then you need to have a separate lisp so the user can setup these "layer-elevations" through it. And then you need to step through all entities modifying those on the layer(s) to their specified elevation. And then as ccowgill suggests use a reactor to set the current elevation according to the current layer's setting - so all new entities also follow suit.

that would probably be for existing drawings, but for the reactor, you could probably set that up as a list within the program itself, so you dont need to getinto ldata/xdata/xrecords. Assuming there are standards in place, and everything is drawn on the correct layer to begin with, however, in most places this is not the case, at least I know here, most of the time, something inadvertently gets drawn with the wrong layer current, then moved to the proper layer. so a change in properties would also have to be included within this reactor. I would say there is no simple way to do it. Perhaps it should be suggested to Autodesk as an AutoCAD "wishlist" item?

Are valuse for Z always going to be constant or variable?

Should be variable layer to layer but constant in its own layer. That is: to define a layer as current, take the elevation value attributed to it.

oh, thats even easier

(if (not Sysvar_Changing_Reactor)
 (setq    Sysvar_Changing_Reactor
    (vlr-sysvar-reactor
      "Monitor System Variable changes"
      '((:vlr-sysVarChanged
         .
         Sysvar_Changed_Command
        )
       )
    ) ;_ end of vlr-command-reactor
 ) ;_ end of setq
 () ;_ the reactor is already loaded
) ;_ end of if

(defun Sysvar_Changed_Command (In_ReactorName In_Command / LayObj)
                   ;(alert (car In_Command ))
   (if (= (car In_Command) "CLAYER")
    (elevationswitch)
 ) ;_ end of if
) ;_ end of defun

all you need is the elevation switch routine

Building on Chris's offering (if I may):

;;;--------------------------------------------------------------------;
;;; SysvarChanged reactor function:
(defun SysvarChanged:Reactors  ()
 (cond
   (*Reactor_SysvarChanged*)
   ((setq *Reactor_SysvarChanged*
           (vlr-sysvar-reactor
             "Monitor System Variable changes"
             '((:vlr-sysVarChanged . Callback:SysvarChanged))))))
 (prompt "\n \n  >>  SysvarChanged Reactors Loaded ")
 (princ))
;;;--------------------------------------------------------------------;
;;; SysvarChanged callback function:
(defun Callback:SysvarChanged  (Rea Cmd / item)
 (cond
   ((= "CLAYER" (car Cmd))                                             ; Layer changed
    (progn
      (cond (*elevList*)
            ((setq *elevList*
                    '(("[color=red]Layer1[/color]" . [color=red]elev1[/color])
                      ("[color=red]Layer2[/color]" . [color=red]elev2[/color])
                      ("[color=red]Layer3[/color]" . [color=red]elev3[/color])
                      ;; ...etc.
                      ))))
      (if (setq item (assoc (getvar 'clayer) *elevList*))
        (setvar 'elevation (cdr item)))))
   ;; ... Add other conditions here
   )
 (princ))
;;;--------------------------------------------------------------------;
;;; Conditional load reactor function:
(defun Reactor:Start  (/ vrsn)
 (vl-load-com)
 (cond
   ((or (vl-string-search "R17.2" (setq vrsn (vlax-product-key)))      ; 2009
        (vl-string-search "R18.1" vrsn))                               ; 2011
    (SysvarChanged:Reactors))))
;;;--------------------------------------------------------------------;
(princ)

Yes, you may,

That is much nicer than what I came up with, I had a foreach function, I bet yours will run a whole lot faster than mine.

Yes, you may,

 

That is much nicer than what I came up with, I had a foreach function, I bet yours will run a whole lot faster than mine.

Much appreciated... this 'rendition' comes from many, many prior failures in working with reactors.