I have four configurations. Two parents, each with 1 child.
I renamed the below features, but they didn't follow through to the rest of the configurations... why?
Is there any reason I would want my features NOT named the same thing in every configuration? That is confusing and problematic.
The LOWER is the child.
So I thought it might be a problem that I tried to change it in the CHILD configuration, so I renamed them in lower case in the parent 42.
This renamed all the configurations except for the child previously changes. Which I guess is understandable.
To test this I renamed child 41 "bird" and it didn't change anything. Ok.
But then I tried renaming a feature "bug" in parent 41, and it changed all but parent 42.. why?
Sarah, have you done ctrl+Q after the name change and then activated each of the configurations?
Steve C
Yes force rebuild did not update/rename the configuration. The "alternate" naming still exists.
yuck!
Steve C
Hi Everyone, I have dealt with one of these and it relates to having derived configs specifically- it is documented as SPR 853199 as below.
if the feature is named with the parent config active, the name seems to propagate through.
Adam
okay so is this model now broken forever?
Sarah, please see attached. This macro will take the feature names of the active config and copy them to the inactive configs to ensure consistency so you can run this every so often to ensure the names are ok. If you can get yourself added to the SPR via your VAR then it will increase the severity.
Adam
Thanks Adam.
So I haven't worked with macros much. What do I do with it?
Sarah, okay so you need to extract the contents and place the macro file somewhere safe on your machine. Then you can create a custom button to it- see this video from about 1min onwards SOLIDWORKS App User Guide | Solid Solutions
Adam
Wow! thanks! It was simple to follow the video to make a custom macro button and I tested it on a backup copy of my file and it did what it was supposed to quickly. So now that button is there forever? Will it work in assemblies too? ..hmm... would it do anything in a drawing?
Sarah, i think it is for parts only to be honest as the macro needs to work on the active model.
and yes when you close SolidWorks and reopen the button with remain on the toolbar. Just ensure you don't move the macro on your PC else the button will lose its link
My biggest question is: What is the criteria of impact particular (this one is medium) bug has? The loudness of victim's cry?
it could be- we ended up writing a macro which when a rename was done it then traversed all in active configs and renamed them all. Let me see if i can find it for you.
I have the same issue minus the derived Configuration... I created a second configuration in a file... made some changes to the Feature names in the DEFAULT config. and they will not carry over to the second configuration. Some of the Features are active in both configs. but the names still do not propagate.
I would rate this as a HIGH impact.... Every time it happens it causes one to do twice the work, plus the fact 20-30 minutes wasted trying to figure out what is wrong, find a fix (NONE PROVIDED HERE..... RUNNING A MACRO IS NOT FIXING THE ISSUE.... IT IS JUST A BAND-AID FOR A MUCH BIGGER ISSUE!!! DASSAULT SHIPPING SOFTWARE WHICH IS NOT READY!!!!
NOW ANOTHER 20 MINUTES MAKING IT RIGHT.... WISH DASSAULT WOULD HAVE FIXED IT BEFORE SHIPPING THIS CRAP!!!
Wow! I have many files from our stock product line that I have revised and thought were now perfect models. Every stinking
one of them is incorrect because of this! I swear I will never re-name a feature again. This was supposed to make thing less confusing but
instead it has made every file incorrect. Pretty ticked about this! Countless hours wasted....and more to come because of it.
Hi Jody, et al
I appreciate this won't help things short term, but for those affected by this bug please reach out to your VAR and ask to be attached with SPR 853199. There may only be the one customer I have dealt with attached to this and so it is not getting the exposure it deserves to become a fix. If we get the 3-4 people on this thread (or more to get it into double figures) then it will become a lot more visible internally with SW and should get attention. The macro I supplied earlier should hopefully get your model back to being correct and then the subsequent rename of features can be done with the Default (parent) configuration active to prevent the issue occurring again.
Adam
I'll give it a shot. Thanks-
Thanks, Adam. I contacted our VAR, and I tried your macro, which works well.
Sarah, How did you make your screen shot with different trees? Could it be that the second tree is in a different window and hasn't had the name changes propagate to it yet?
If that's not it, you could create an Auto-create design table and then delete every other configuration keeping only one and then recreate them by opening and closing the design table. Every feature name should now be the same in every configuration.
I see conflicts often where configurations don't update correctly and the method above always resolves them. Sadly, the conflicts reappear again sometimes so I have to delete and recreate configurations again.
Hmmm... that is an interesting idea, with the design table to re-make the configurations.
MS Paint and Snipping Tool are my go-to when I need to create a visual. So no, I do not have multiple windows open when I see this bug. Good thought though.
I've experienced the same problem with standard configurations. So much time is wasted having to track down fixes for all the bugs in Solidworks. I spend an inordinate amount of time working around all these issues. Time that should be spent finding a good design solution.
The only thing that I can think of is that they have the same name, just switched. I am guessing that this is confusing Solidworks.
Try Renaming just one to something different, walk through your configs, save, rename the 2nd one something different, walk through your configs, save, then name them what you want and walk through the configs and save again.