cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can subscribe to a forum, label or individual post and receive email notifications when someone posts a new topic or reply. Learn more! X

Updating Renamed 'def_latyer' Layers

dgschaefer
21-Topaz II

Updating Renamed 'def_latyer' Layers

WF4 / WF5



We have a client that uses config.pro 'def_layer' statements to define
their layers (this is their company wide standard; changing it is not an
option). They have adopted new layer names as part of their migration
from WF4 to WF5. We have an ongoing project with them, started in WF4
but will be delivered in WF5. I need to deliver files with their new
layer names.



So, currently I have layers with the old name, tied to the old
'def_layer' statements. If I simply update the config.pro with the new
'def_layer' statements, I'll end up with duplicate layers, one set with
the old names and existing features but no longer tied to any
'def_layer' statements, one set with the new names and any new features
tied to the new 'def_layer' statements.



The cleanest way forward seems to be to remove the 'def_layer'
statements, rename the layers in all parts & assemblies and then add in
the new 'def_layer' statements. Is there an easier way that I'm
missing?



Doug Schaefer

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.
--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn
8 REPLIES 8
bgruman
12-Amethyst
(To:dgschaefer)

Doug,

There may be a better way,  but here is what I did for a client once.
They changed their 'def_layer' statements and implemented for all users.
Then suddenly realized that all of their old parts (now modified with new
features) were showing the duplicates.   So,  it took some doing,  but I
built them a mapkey and called it "update_Layers"  It one-by-one selected
the old layer name, cut all included items, then selected and pasted to the
new layer name, then finally deleted the old (now empty) layer.    Its been
a while since I did this,  but I remember creating the mapkey was painful.
   Once it was created though,  using the mapkey was a snap!

Good Luck,   Hopefully someone out there knows of an easier way.
Bernie

Bernie Gruman
Owner / Designer / Builder
www.GrumanCreations.com


On Thu, Mar 15, 2012 at 2:06 PM, Doug Schaefer <
> wrote:

> WF4 / WF5****
>
> ** **
>
> We have a client that uses config.pro ‘def_layer’ statements to define
> their layers (this is their company wide standard; changing it is not an
> option).  They have adopted new layer names as part of their migration from
> WF4 to WF5.  We have an ongoing project with them, started in WF4 but will
> be delivered in WF5.  I need to deliver files with their new layer names.*
> ***
>
> ** **
>
> So, currently I have layers with the old name, tied to the old ‘def_layer’
> statements.  If I simply update the config.pro with the new ‘def_layer’
> statements, I’ll end up with duplicate layers, one set with the old names
> and existing features but no longer tied to any ‘def_layer’ statements, one
> set with the new names and any new features tied to the new ‘def_layer’
> statements.****
>
> ** **
>
> The cleanest way forward seems to be to remove the ‘def_layer’ statements,
> rename the layers in all parts & assemblies and then add in the new
> ‘def_layer’ statements.  Is there an easier way that I’m missing?  ****
>
> ** **
>
> *Doug Schaefer
> *****
>
> ** **
>

Model Check can rename the old layer to the new name. No manipulating features from one layer to the next & layer rules stay in place. Probably the cleanest option for what you're describing.


Should even work if you have the old layer and the new layer in the same part, though I haven't tested specifically for your question. It'll simply move the old layer items to the new layer, effectively merging the two.

In Reply to Doug Schaefer:


WF4 / WF5



We have a client that uses config.pro 'def_layer' statements to define
their layers (this is their company wide standard; changing it is not an
option). They have adopted new layer names as part of their migration
from WF4 to WF5. We have an ongoing project with them, started in WF4
but will be delivered in WF5. I need to deliver files with their new
layer names.



So, currently I have layers with the old name, tied to the old
'def_layer' statements. If I simply update the config.pro with the new
'def_layer' statements, I'll end up with duplicate layers, one set with
the old names and existing features but no longer tied to any
'def_layer' statements, one set with the new names and any new features
tied to the new 'def_layer' statements.



The cleanest way forward seems to be to remove the 'def_layer'
statements, rename the layers in all parts & assemblies and then add in
the new 'def_layer' statements. Is there an easier way that I'm
missing?




Bernie - Yeah, a mapkey seems to be the way to go, but I'm thinking I
want to do it before the new 'def_layer' statements are in place. Then
I should be able to simply rename the layers and all would be good. No
swapping of items from one to the other, so a much simpler mapkey.



Don - These aren't rule based layers, these are defined but config.pro
'def_layer' statements. Similar functionality, but they work completely
different. Using model check for the rename is a great idea, but I've
never used it. I may have to check into it.



Doug Schaefer
--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn

Model Check doesn't really interact with rules. It's just that if layer rules exist, it will preserve them while both renaming the layer and keeping the features on that layer.


I think the mapkey method will also work. Model Check will be the cleanest and least painful route, depending upon how much time you want to spend checking into it and setting up a simple configuration.

In Reply to Doug Schaefer:


Don - These aren't rule based layers, these are defined but config.pro
'def_layer' statements. Similar functionality, but they work completely
different. Using model check for the rename is a great idea, but I've
never used it. I may have to check into it.



Doug Schaefer









I use this feature in Modelcheck all the time, but it is a multi-pass
feature.



First you run Modelcheck and it tells you to add the layers missing and
delete the unwanted layers.



Run Modelcheck again and it will tell you that there are features that
belong on the layers, and the layer display status needs updated for the
new layers (blank/unblank)



As you add features to your model you need to run Modelcheck
periodically to add these features to the layers, as there are no rules
embedded.



I really wish that there was a way (XML files?) to save and retrieve
default layer schemes including rules. (Creo 2-3, maybe?)



I don't know if you can automatically run Modelcheck in batch mode, but
I would hope so.





Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317

There is a ModelCheck batch mode. I've never run it, so I can't comment
to its efficacy, but it does exist.


I do not want to and cannot change the content of the layers, only
rename them. Can model check be configured to so something like 'if you
find a layer named XXXX rename it to YYYY'? Add a new layer and delete
the old and then add the items isn't likely to work for me.



Doug Schaefer
--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn

That's exactly what Model Check will do.


Announcements
NEW Creo+ Topics: PTC Control Center and Creo+ Portal


Top Tags