Change selected standard layers from New to Existing

[Anonymous]

Hello,

This lisp I am looking for is probably pretty basic, and would be great at a basic level but may get into the weeds with further customization with my company's blocks with attribute text layers etc.  

Overall, I am looking to get help creating a lisp with likely an ssget command or option for select all (current space model/paper) or current selection specific, to change standard company layers from New to Existing versions of those layers.  An example standard layer we have is M-EQPT-NEW (Mechanical Equipment New) or M-EQPT-EXST (Mechanical Equipment Existing) both with layer colors dictating a bold vs light lineweight in our .ctb file to differentiate new from existing work.  

I feel like this is something possibly achievable with LAYERTRANS but maybe it doesn't have the customization that a lisp would have for selection set to more specifically target what you need changed.  Another more specific problem is the text fields in said blocks have a text layer M-ANNO-NEW vs M-ANNO-EXST with colors as well.  Because of this often the same block has two different definitions, a new vs an existing.  But often this is not an issue because the text is not shx text it is ttf text which will not bold or lighten on plots based off the .ctb, more for layer management and visual clarity while in AutoCAD.  I have no problem it remaining the same block but just changing the attribute text layer by instance vs globally in said drawing.

The necessity for this is something that comes up often because a 'legacy' AutoCAD job has to be resurrected and new work done in some area but everything else needs to be converted to existing conditions for the new project. 

From a basic standpoint I could imagine the programming routine to go as follows:

1. Select set  (ssget?) or All of current Model/Paper space
2. Convert from New to Exst, or Exst to New
3. Utilize layertrans from predefined definitions for layers with settings.  Some standard layers may not exist in the drawing yet, will this achieve creating them?  Conversely, instead of layertrans maybe layers be created based off necessity?  All layers are by standard named consistently aside from the ending suffix -EXST or -NEW.  Maybe it could just point to a definitions list for those layers colors and from selection create a list of selected -NEW layers and only generate the inverse -EXST layer for each it encounters.
4. Set those objects to that layer from list, is there a way to dig into the block (BATTMAN?) to swap the text layers in the attributes as well?
5. Close command.

I am kinda lumping a lot in the middle there, specifically step 3, but this could go different ways.

Thanks in advance for any help!

-Warren

[Moshe-A]

@Anonymous  hi,

Not sure i understand why you want to select objects for only rename layers

check the following command

enjoy

moshe

(defun c:new2exst (/ tbl newLayerName exstLayerName p)
 (setvar "cmdecho" 0)
 (command "._undo" "_begin")
  
 (while (setq tbl (tblnext "layer" (not tbl)))
  (terpri) 
  (princ (setq newLayerName (strcase (cdr (assoc '2 tbl)))))
  (if (and
	 (not (vl-string-position (ascii "|") newLayerName)) ; skip xref layer
	 (setq p (vl-string-search "-NEW" newLayerName))
         (not (tblsearch "layer" (strcase (setq exstLayerName (strcat (substr newLayerName 1 p) "-EXST")))))  
       )
    (command "._rename" "_layer" newLayerName exstLayerName) 
  )
 ); while

 (command "._undo" "_end")
 (setvar "cmdecho" 1)
   
 (princ) 
)
  

[Anonymous]

Thanks for this, I'll experiment with it.  Problem is sometimes on projects we also have one area that gets built and needs to go as Existing and another that still needs to stay New, so I can't just rename layers and change the properties because there are elements that need to remain on the -NEW layer and that layer shouldn't be changed.  Specifically we may have phasing to a project that comes about after a bunch of work is already done and we then need to split the "NEW" into a future phase.  Another Layer that exists is -FUTR, for this specific project, but that is not always a standard.  I am also thinking this would affect our existing block definitions for that drawing when a new one is brought in from our lisp item toolbar it would not appear new but existing because the actual layer would have changed in the definition.

Does this make sense?

Thanks

[john.uhden]

For simplicity's sake, let's say that all/most of -EXST (whatever) layers shall be color 8.  That's what we use for physical features, though lot lines and R.O.W. lines are more of a legal thing and are black of varying lineweights and linetypes.

That would mean that each -NEW layer item would be changed to -EXST, but if the layer does not already exist, then we create it and make it color 8.  Of course that doesn't solve the linetype issue, so the recommended answer is to insert a block with all the possible -EXST layers included with desired color and linetype.  Okay, a few will not be in the -EXST list like maybe NUCLEAR-WATER-HEATER because they may not yet exist, so the exceptions can be any color and linetype you want, maybe even like 230 (fuschia) which ought to grab anyone's attention so they will know to change them manually.

Of course, this all reminds me of discipline differences.  As a civil type, we always used PROPOSED, but even that is predominantly for private projects requiring some kind of government approval.  An existing fire hydrant may be brand new.  The clearest approach I have ever seen is the use of construction notes that start with "CONSTRUCT" or abbreviated "CONST."  But all we are really discussing here is layer organization, so my apologies for digressing.

[Anonymous]

Interesting points John, specifically the block definition part that caught my attention. 

Yes the cleanest way would be have it pull in the associated standard block which might be another large component to the lisp, if the lisp had a database of all our blocks and the exst equivalent of any given new block definition.  I may have to dig into the routines which control our block generation as we have a lisp toggle which I believe changes a drawing variable for all our custom lisp toolbar buttons from Existing to New when placing new objects (ie. we can switch the toggle button to E for existing and when I go to place a block from another button it knows to grab the existing mapped version instead of the new and I can place a 'fresh' block somewhere displayed with all the existing layer properties.)  This could be controlled by naming conventions of the blocks but maybe not, so I'll try to read the lisp and grab that component.

Doing this on an as needed basis instead of loading an entire block library would probably be the preferable route.  I know there is the possibility of just loading the entire library of standard block definitions, but file size would come into play then.  Purging everything out afterward presents its own set of problems, maybe I have custom layers that I don't want to lose but aren't being used currently they would purge out.  As far as layers are concerned one option might be to just load all missing layers in one go, but again, not as elegant.   I do know that I could import a layer state and maybe automate this via lisp or script that would accomplish that.  This would also change any layers that maybe have outdated settings for that same named layer updated to the current standard. 

[john.uhden]

I think you have to start thinking about doing what YOU need, not to what
AutoCAD confines you. That is the beauty of programming.
Reading .TXT files with AutoLisp is very quick. Rather than inserting a
block with all the layer definitions, it would be just as fast to read a
LAYER-EXST.txt file and create any new (not -NEW) layers as needed with
their prescribed color and linetype. CAUTION... that'll probably mean that
you would have to add all your special linetype definitions to ACAD.LIN so
AutoCAD can find the on its own.
No problem. I have a WLTYPES.lsp program that writes all linetype
definitions in a DWG to ACAD.LIN.
BTW, might you be related to a Jim Churchill who grew up in Point Pleasant
Beach, New Jersey?

[Anonymous]

I agree with the approach of doing what I want aside from what I am confined to.  I was just listing those out of the box commands/express tools as there might be some code inherent to those that could be referenced/recycled for these purposes.  I am pretty sure we already have a .lin standard setup but I'll verify if I can tomorrow.  The beauty of our layers is we probably don't have varying linetype between the New vs existing versions, for instance we have a different layer for underground (dashed) conduit vs above ground (continuous linetype) and then existing and new variants for each.  

As far as the relation is concerned, not to my knowledge.  I'm from Colorado and that side of my family goes back to around the gold rush here.

Thanks

[john.uhden]

The only thing that really bugs me about linetypes is that you can get an obliqued complex linetype only by referring to a text style that is obliqued or a font that is italicized, and such may not exist until it is defined.  Wait a minute, I think even sometimes the obliquing of a text style is ignored.  I come from the school where all existing text should be slanted and all proposed should be straight up and down.

------- W ------- existing

------- W ------- proposed (or new) 🙂

Oh yeah... your graphic profile reminds me of someone... Alfred Hitchcock?