custom properties not sticking...

Is there a Design Table? If the props are controlled by a DT and the DT is locked, the changes won't "stick".

That70sTick wrote in news:1180472405.938365.146090 @g4g2000hsf.googlegroups.com:

I usually get a warning when I try to do that. Maybe the OP's client found a way around that.

Another possibility is that the part model is read-only, and SW is set to discard changes to read-only parts without notifying the user. There should be a warning when opening the read-only part though...

That70sTick wrote in news:1180472405.938365.146090 @g4g2000hsf.googlegroups.com:

I usually get a warning when I try to do that. Maybe the OP's client found a way around that.

Another possibility is that the part model is read-only, and SW is set to discard changes to read-only parts without notifying the user. There should be a warning when opening the read-only part though...

I have seen this problem with the following scenerio:

We have an add in that automatically populates the custom properties from a predifined template file. What happens with SW is that it does not like to have the same property name in both config specific and global, so if I where to add say "material" as a config specific property and then later come back and initiate my addin it will delete "material" in the configuration and add it to the global list. So the point is that you cannot have the same name in both global and config specific custom prop. lists.

Below is another oddity I have noticed and have got my VAR to submit to SW:

If I am using config. specific properties I have noticed the following behaviour:

create a simple part and add a configuration so that you have the names 1 and 2

go to for config 1 add a property "material spec" and another "bom"

for the value enter aluminum for material spec and $PRP:"material spec" for the value of bom

Now go to config 2 and enter exactly the same custom property names and enter "steel" for the value of material spec and $PRP:"material spec" for the value of bom

If you now look at the evaluated value for the property "bom" you will see that one or the other is taking the value from the other configuration and not from the value for the config that the expression is in.

Any ides about whats going on? my expectation would be that the expression whould take the value from the config it is in but that is not happening.

It must be your add-in that doesn't like to have custom and config specific properties with the same name. I have been doing this in base SW since 99. Config specific properties override custom properties when the config specific property with the same name exists. So, you can have custom property "description" contain "SHCS" for all configurations. If a configuration has config specific property "dscription" that contains "BHCS", any reference to "description" for that configuration will report "BHCS" instead of "SHCS".

With reference to the behaviour noted below coincidentally I just received an update from my VAR:

"Configuration specific properties do not update correctly

I have reported this issue to development in SPR 382800 "Configuration specific custom property does not update correctly. The custom property's evaluated value only reflects the active configuration"

You will be notified when this is resolved."

Steve R

"> Below is another oddity I have noticed and have got my VAR to submit to SW: