Community
@iwafb wrote:.... the programs unlock all the possible layers and the user is able to manipulate the objects. Once finished, the layers get locked up again. ....it takes about 10+ seconds for the program to go through the lock or unlock process....
....is there an alternative way to lock/unlock layers in lisp which might process a bit quicker?
....
Try something like this:
(setq layUlist ; list of locked layers among those in pdpurlinlist
(vl-remove-if-not
'(lambda (lay)
(= (logand (cdr (assoc 70 (tblsearch "layer" lay))) 4) 4)
); end lambda
pdpurlinlist
); end vl-remove-if-not
); end setq
(foreach lay layUlist ; unlock those layers
(setq
laydata (entget (tblobjname "layer" lay))
laydata
(subst
(cons 70 (- (cdr (assoc 70 laydata)) 4))
(assoc 70 laydata)
laydata
); end subst
); end setq
(entmod laydata)
); end foreach
;;;;..........do your thing to the objects..........
(foreach lay layUlist ; re-lock those layers
(setq
laydata (entget (tblobjname "layer" lay))
laydata
(subst
(cons 70 (+ (cdr (assoc 70 laydata)) 4))
(assoc 70 laydata)
laydata
); end subst
); end setq
(entmod laydata)
); end foreach
Kent Cooper, AIA 
@iwafb wrote:....
(setq pind 0)
(repeat (length pdpurlinlist)
(command "_.-layer" "unlock" (nth pind pdpurlinlist) "")
(setq pind (+ 1 pind))
)....
By the way, though it may not save any time if the (command) approach is the cause of the delay, there is a simpler way to do this, when it's a list you're working on [not, for example, a selection set]:
(foreach lay pdpurlinlist
(command "_.layer" "unlock" lay "")
)
But that still invokes the (command) function for every Layer involved, which is likely the biggest time-consumer. It probably would save time, even if using (command), to use it only once:
(setq layUlist ""); initial empty string
(foreach lay pdpurlinlist (setq layUlist (strcat layUlist lay ","))); comma-delimited string of Layer names
(command "_.layer" "_unlock" layUlist "")
Your original and these other approaches would unlock all Layers in the list. But your original message suggests that you would need to know which are locked when you start, so you can lock them again later, without also locking Layers that were not locked when you started. That made me think maybe your pdpurlinlist was already a list of only locked Layers, but that doesn't jive with your statement that "if the layers are already unlocked, the code gets executed almost instantly." I don't know how you've been doing the re-locking [maybe you've been locking Layers that were unlocked before], but my earlier suggestion makes such a pared-down list, so you can use it again later to re-lock only the Layers that were locked.
Kent Cooper, AIA
Might the faded color feature of locked layers have something to do with the delay? Seems that as each layer is locked/unlocked the screen would be updated, which could account for the extra time involved.
----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
@iwafb wrote:....
The only difference I can see in the two function is the + or - in the cons line. I kind of assumed this would be the switch to lock/unlock the layer, which seems to be the case witht he - (unlock). However, the + (lock) seems to work more as a toggle? That is if the layer is locked it will unlock it and viceversa. Is that the way it works?
....
The information about a Layer that you get from either
(tblsearch "layer" "YourLayerName")
or
(entget (tblobjname "layer" "YourLayerName"))
contains an entry that looks like this:
(70 . 0)
except that the second number isn't always a 0. It's a binary-bit code that holds information about a couple of things. If it's 0, the Layer is thawed and unlocked. If the Layer is frozen, that second number includes the 1 binary bit. If it's locked, it includes the 4 bit. If it's frozen but not locked, it will be 1; if it's locked but not frozen, it will be 4; and if it's both locked and frozen, it will be 5 [the sum of the other two]. I'm not sure whether other binary-bit numbers [2, 8, 16, etc.] are used, but knowing that the 4 bit is about locking is all that's necessary here.
If a Layer is locked, the number paired with the 70 will be 4 or 5 [or if 2 is used for something I'm not aware of, possibly 6 or 7, etc., but always something whose makeup as a sum of power-of-2 integers includes a 4] -- subtracting 4 from whatever it is will unlock the Layer. If it's unlocked, that number will be 0 or 1 [or 2 or 3 or 8 or 9, etc., but always something whose powers-of-2 makeup does not include a 4] -- adding 4 to whatever it is will lock the Layer.
The (cdr) functions find the current value paired with 70, the (cons) functions pair the result of subtracting or adding 4 from or to that with a 70, the (subst) functions replace the old 70-code pair with the new one, and the (entmod) functions impose that change on the database.
Kent Cooper, AIA
@markruys2 wrote:you can use a simpler approach
(command "._-layer")
(foreach lay laylist (command "_unlock" lay))
(command "")
[Look back at Messages 3 for a similar approach, and 7 for confirmation that the (command) function was apparently the cause of the slowness. I imagine nesting (command) functions inside each other would only exacerbate that.]
Kent Cooper, AIA
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")
