cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Corporate Mapkeys - Superseding User Mapkeys

Re: Corporate Mapkeys - Superseding User Mapkeys

I think there is another way you could solve this. On our other network, none of the computers have local hard drives. I have Creo installed on a network share. Rather than placing loadpoint configs down where they would get wiped out if I installed a new build, I have them in another folder on that same share.

My startup script builds the start-in-dir config file every time by concatenating several files together to make the one config. Something like this:

echo y|copy "P:\configs\core-config.txt"+"P:\configs\core-mapkeys.txt"+"H:\pro\Creo_2_Home\configs\my-config.pro"  "H:\pro\Creo_2_Home\config.pro"

That combine three config files into one in the start in dir.

P: is the network share location

H: is the users home directory on a netapps server

The users config is in a sub dir of the start-in-dir, and it always has to be named my-config.pro.

One advantage is if the user doesn't know enough to use the config editor to store the config file to this location. then they are less likely to use it and just enter stuff manually. That in fact is what I tell them to do. Use the config editor to find the option and then manually enter it. 

Now, if you change the order of the files your concatenating, You can place your system mapkeys last in the resulting file, so if there are any duplicates yours will trump theirs because they got read last.

You don't need any trail files to do what you want.

Re: Corporate Mapkeys - Superseding User Mapkeys

We run all of our Creo installations locally on each user's machine. I think the issue is related to just poor network performance at some locations not just having a Windchill replica server near as it can affect all network drives not just Windchill. Having just one network installation is definitely a neat idea (and would simplify the administration greatly) but I don't think we can count on speedy networks all the time especially if people are traveling.

Re: Corporate Mapkeys - Superseding User Mapkeys

These are all good ideas here. I would guess my solution be:

  1. Some combination of David Haigh‌'s build the startup config.pro on the fly or Doug Schaefer‌'s comment about reordering the way we use the config.pro's. The theme is the corporate mapkeys would need to get loaded last.
  2. Leave it the way it is with users overwriting the corporate mapkeys and deal with will complaints as they come up. This doesn't sit well with me as I'd really like to move the company forward with using a consistent set mapkeys across all users.

I'll try to let you guys know which way we end up going with this. Thanks!

Re: Corporate Mapkeys - Superseding User Mapkeys

Regarding point #2, I'd gently challenge your thinking there depending on the purpose of your corporate mapkeys. 

If they are there to insure consistency in following corporate policies and standards, then, yes, invest the time to make them tough to override. 

If they are there to simply help users save time and clicks, then making sure everyone has the same mapkeys isn't as important.  In that case, allowing users to define their own, even if the override the company mapkeys, may allow them to be more efficient.

--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn

Re: Corporate Mapkeys - Superseding User Mapkeys

Great point. For these corporate mapkeys, most of them are consistency/process standardization (e.g. making a new DXF with the appropriate things hidden and latest STD DXF note) and the rest are nice time savers. We've been playing telephone/manually pass the semi standard mapkeys/std drawing notes/std drawing tables with 50+ people. Change doesn't work well with that setup as the revision of each ends up all over the place. This group usually get pretty frustrated when we change Creo versions as they have to play telephone again or be their own admin on the mapkeys they never created. My thought was users are always welcome to create their own just not with the same names as they can be quite good at solving their problems. As they/we come up with new or better mapkeys (or the standard process changes), we could share them with everyone. If I didn't want them to create their own, I would load these into the config.sup but that's just a bad idea since no one could create their own mapkeys.

Re: Corporate Mapkeys - Superseding User Mapkeys

If I didn't want them to create their own, I would load these into the config.sup but that's just a bad idea since no one could create their own mapkeys.

Actually, you can't.  Mapkeys won't work in the config.sup.  With the exception of one specific option, no command is allowed to be duplicated in the config.sup file.  Mapkey statements by their very design have duplicate commands - "mapkey".

Re: Corporate Mapkeys - Superseding User Mapkeys

Not only do mapkeys in the config.sup prevent user mapkeys, I think only the first one will work.  Any further mapkey statements are prevented, even if they are in the config.sup.

--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn

Re: Corporate Mapkeys - Superseding User Mapkeys

Actually, you can't.  Mapkeys won't work in the config.sup.  With the exception of one specific option, no command is allowed to be duplicated in the config.sup file.  Mapkey statements by their very design have duplicate commands - "mapkey".

My testing does not appear to support that in Creo 3 M060. Our config.sup is located in C:\Program Files\PTC\Creo 3.0\M060\Common Files\text.  All the the mapkeys in the config.sup seem to work fine but it appears prevents any mapkey in any other config.pro from working.

Re: Corporate Mapkeys - Superseding User Mapkeys

Interesting, that's a change then.  I wonder when that went into effect.

--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn
Highlighted

Re: Corporate Mapkeys - Superseding User Mapkeys

Are you sure ALL the mapkeys in the config.sup actually worked?  According to PTC, only the first mapkey listed in the config.sup should work.  All the others will be ignored.

https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS44710

Announcements