How to make a derived config the only config?

[bnemec]

Looks like we made a few mistakes with configurations, now trying to repair the damage. We have the configs "organized" in derived configs now making a plan to go to one part per file we want the one config to be the top level, sole config. So, I try copy of the master config file, delete all the other configs except for the one part that this file will become but I still have it buried under a couple parent configs. I can find no way to undo that, more or less break the derived link to the parent config. I looked in the API, but not finding much. Actually, I'm not even finding a delete config option in the API (IConfiguration or IConfigurationManager)

Anyway I'm starting to think the only way to do this is edit the root config to make it like the one config I want to keep. Any suggestions on how to take a single derived configuration and make it the only configuration in the file?

Thanks.

[Tom G]

Not certain, but a ham-fisted idea. Create a design table that automatically captures all the differences in the configurations which are left. Edit the design table to copy all the settings for the good config into the root config. Check that it came through with intended features, then clean up or rename what's left.

I ran into the same thing a couple weeks ago, and decided to leave it as-is instead of fussing through a workaround because in my case, it is a rarely used part.

[bnemec]

Not certain, but a ham-fisted idea. Create a design table that automatically captures all the differences in the configurations which are left. Edit the design table to copy all the settings for the good config into the root config. Check that it came through with intended features, then clean up or rename what's left.

I ran into the same thing a couple weeks ago, and decided to leave it as-is instead of fussing through a workaround because in my case, it is a rarely used part.

I like this idea. Going to try it now, but will take a bit. It takes >1/2 hr to generate the design table. But If I delete all the configs except for the one needed and the parents that should go quickly, then copy the values of the desired config to the root.

[Marshall Wilson]

Never tried this with a complex derived configuration, but - with the derived configuration active, can you use the "Add Configuration..." (with RMB menu)? Doesn't that create a New top-level configuration with all the properties etc of the previously active configuration?

[jcapriotti]

I looked in the API, but not finding much. Actually, I'm not even finding a delete config option in the API (IConfiguration or IConfigurationManager)

Yeah, we look onto this years ago and the api doesn't support it. There appears to be no way to un-derive a configuration. Like suggested, create a new configuration off of it will retain the changes. Unfortunately this will cause problems in assemblies that use it if you have more than one configuration still in the part. Deleting a config is generally bad for this reason but I'm not sure you have much choice.

[the_h4mmer]

Not certain, but a ham-fisted idea. Create a design table that automatically captures all the differences in the configurations which are left. Edit the design table to copy all the settings for the good config into the root config. Check that it came through with intended features, then clean up or rename what's left.

I ran into the same thing a couple weeks ago, and decided to leave it as-is instead of fussing through a workaround because in my case, it is a rarely used part.

I know this is an old thread, but ran into this issue and stubbled across this thread when I was researching this. Can confirm, Tom's solution does work!

[bnemec]

I should have followed up on this thread. My mistake.

for posterity here's a related thread:
https://www.cadforum.net/viewtopic.php?t=602
https://www.cadforum.net/viewtopic.php?t=895 Jim Sculley had same answer in this thread, which I don't know why I started a new one, I must not have been able to find this one.

I was not able to get the design table idea to work. Several reasons probably, one the design table took ~ half hour to load each time I tried something with it. I don't know how I would have implemented that action in API either. Secondly, I vaguely recall there being some columns in the design table that couldn't just be copied, some had to stay the same. I don't recall the details on that, but it probably could have been figured out, maybe not by me though.

What I wound up doing is pretty much automating what @Marshall Wilson suggested; select the desired config, make a new root config; which is a copy of the active config, an important yet simple concept that I didn't know at the time.

The total process that I automated was:
1) open the configured file
2) get a list of the part numbers in the file from the configurations and loop through them
3) save the configured file named by next part number in list and open that file
4) activate the config whose name matches the part number in list
5) create new root config
6) delete all the other configs
7) get a list of all the feature tree objects that are suppressed
8) loop through the list of the suppressed features deleting them (this was messy and still didn't work perfectly due to dependencies)
9) save the new file again and close
10) check the new file into the vault with useful comment
11) loop to step 3