Mapkeys Loading Issue from Different Config.pro

[jwagh]

I am updating old company mapkeys.

Based on what I've discovered, it appears that the home directory config.pro will override the mapkey from the loadpoint config.pro if the mapkeys have the same name. Since many people have made their personal config.pros from the loadpoint version (and placed it in the home directory), they now have old mapkeys. How do I get the new versions, which will be on the loadpoint, to run when they type in the mapkey prompts?

Thanks in advance for all of your help!

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.

[dschenken]

In order of likely to work, but risk irritating people:

1) You can delete everyone's local config.pro, which may not make everyone happy as it will also take out the customization. This can be done with software deployment tools.

2) You can move everyone's local config.pro to a new name and let those who like what they had copy the pieces they want to keep. This can be done with software deployment tools.

3) Edit each local config.pro and comment out all the mapkeys or cut all the mapkeys and paste them to a new file. This is more difficult as scripting is involved, but the mapkeys are identifiable with ordinary text editting techniques. It can probably be done with software deployment tools.

4) Generate a list of the new mapkeys for the users and let the users sort them out. This works best if they have some understanding of how mapkeys get appended to their local config.pro without their realizing they are sometimes copies of the loadpoint mapkeys.

Depending on the users and the level of work-environment rigidity any of these is a possibility.

Keeping the majority of the mapkeys out of the config.pro file is a good idea. They can stay in a text file and get loaded with the only mapkey that needs to be in the config.pro (or manually if you like) which keeps the config.pro file orderly and lets the mapkeys get easily editted using Notepad or the like. Being independent one can have several sets of mapkeys dedicated for particular jobs.

[jwagh]

thanks for the response:

1)I don't think this would make people happy if I have to do this for every change to the companies mapkeys..

2)I don't think this would make people happy if I have to do this for every change to the companies mapkeys.

3)People like their custom mapkeys, which I would want them to keep. I don't want them commented out.

4)Many users have a weak understanding of the config.pro and mapkey logistics

We are pretty rigid with our Pro/E setup. I would definitely want to look for a solution that is easy to roll out changes without interfering in people's work.

I'm not sure I understand that last suggestion. I don't want to force the users to do extra steps to get the company mapkeys to work.

[dschenken]

About the last suggestion, one can create a mapkey that loads the other mapkeys. This is the only mapkey that would be in the config.pro. To use the remaining mapkeys, just run the one and it loads all the others from another file.

Commenting out all the mapkeys still allows them to uncomment the ones they like, even the ones that override the ones you are trying to get them to use. It also means they have to put a little effort in removing the comments and some thought about it being a good idea. Until they do, the new mapkeys are used and the old mapkeys are not deleted, just resting in plain sight, so the users aren't so aggravated as in the first two scenarios.

I think (4) is attractive because it easily separates mapkeys from the config.pro and makes it more obvious that there is a place for their mapkeys separate from company standard mapkeys.

The mapkey-loads-mapkeys concept translates into mapkeys that can function as toggles. In a file called ON is a mapkey called Toggle. When run, Toggle loads a file called OFF that also contains a mapkey called Toggle. When run, Toggle loads the file call ON again. The Toggle mapkey in ON also changes something like setting datum display to on, while the Toggle mapkey in OFF changes that same setting to OFF.

The toggle ability is not available if all the mapkeys are in the same file because only the last definition of Toggle will be kept.