Config.win loading

[dr_gallup]

I have been working on my personal config.win file. I've added some nice mapkeys as icons in the sketcher & drawing toolbars & added some custom flyout menus. Everything works & has been nice & stable. So I decided to roll this new config.win out for everyone. I copied my config.win to the loadpoint/text directory (network install) & made sure it had a higher rev number. Fired up Pro/E (WF2 M220) & it acts like there is no config.win loaded at all. If I go to tools/customize screen & try to load my home dir file it ignores that too.

I tried deleting the version in my home dir, no luck. I went back to the old load_point/text config.win & my home dir config.win & it's all back to normal. I copy my home dir config.win to the loadpoint/text dir & it all quits working again. I've looked at the config.win file and there is nothing in it that contains a path statement or anything like that. Why does Pro/E care where the file is loaded?

Edited by: dr_gallup

 

[dr_gallup]

I think I have it figured out. We all know that config.win loading is cumulative, just like config.pro loading. However, it seems that saving a config.win does not necessarily save the complete current status. I started Pro/E up, did a tool/scustomize screen/default. Then I loaded the original system config.win & then loaded my personal config.win and saved back to my home dir. This saved a much bigger config.win file. I moved this file to the system dir so it is the only config.win file loading and all is well.

This new file is bigger than the 2 previous files combined. Any way to compact these files or do they just keep growing like bloated windoze registries until everything crashes?

 

[skraba]

I think config.win is growing like current_session.pro does. It accumulates all the config.win files it finds on paths defined for Pro/E.

 

[proed]

dr_gallup
Like you, I've discovered quirks with config.win thru the years... my latest
plan is to create config mini-installers for users to select if they want,
that'll place the appropriate config.win file in the text folder.

However, as you suggest, the results are not always predictable,
depending on what config.win files already lurk in the text folder and/or
user folders. I was thinking of letting the installer rename config.win* but
that's maybe overkill?

I wonder if an enhancement request is worthwhile? - a nicer editor for
config.win would be handy...
Ed

 

[dgs]

One of the problems is that they have memory. Here's what I observed:
<UL>
<LI>Create2 config.win files, file #1 in the text folder and file #2 in the start in folder
<LI>Start Pro|E so that only file #1 is loaded (temporarily rename #2 or move it)
<LI>Add a drop down menu in file #1 with some commands in it.
<LI>Now remove that drop down menu and save file #1.
<LI>Re launch Pro|E, this time with only file #2 loaded
<LI>Add in a new drop down menu in file #2 and save it
<LI>Now, relaunch Pro|E so that both files load.</LI>[/list]


Since file #2 loads last and has the menu in it, you'd think that the menu would be there. Nope. File #1 remembers the add and remove instructionsrather than simple removing the reference to the menu, so the remove in file #1 overrides the add in file #2 so no menu. Completely counter intuitive.


I suspect there are a lot of goofy things like that inside those config.win files.
Edited by: dgs