Corporate Mapkeys - Superseding User Mapkeys

[lhoogeveen]

I'm trying to roll out corporate wide mapkeys that will supersede users mapkeys if they have the same name to avoid users calling and saying the standard mapkeys aren't working (similar to to config.sup vs .pro but that discussion is closed and written in 2012). We're using Creo 3 M060.

I've created a trail file that for opening Creo and setting the mapkey.pro file I created and have attached it to the icon. After clicking on the icon... Creo opens, mapkeys load fine but it disconnects all the Windchill servers. Normally when starting Creo at our company, Creo prompts users to sign into Windchill (I think b/c our start parts in our config.pro are in Windchill). This Windchill sign-in menu selection doesn't appear in the trail file so I can't have the trail file click ok. The servers are just missing not just 'working offline'. Removing the trail file from the Creo start icon brings the servers right back.

I've tried using long (full start up sequence with loading mapkey.pro) and short (only load mapkey.pro steps) trail files.

Is there a way around this? Or a different method for superseding users mapkeys? I could make a mapkey called 'load' for users but that doesn't work great with the creo_parametric_admin_customization.ui mapkey menu I made on a separate tab and requires users to remember to type 'load'. The config.sup unfortunately isn't a good option for mapkeys (I wish it was) because then users can't create their own mapkeys.

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.

[dgschaefer]

I don't have experience with Windchill, so I'm not 100% certain how this will apply in a WC environment.

That said, Creo loads config files from 3 places (maybe others with WC):

1. The text folder of the Creo loadpoint (config.sup mus tbe here)
2. The user's home directory (Windows environment variable)
3. The startup folder as specified by the launch icon.

If you place your user's config file in one of the first two and your company file in the 3rd, your company mapkeys will take precedent.

Here, the company files go into #1 and the user files in #3.  If a user made a mapkey that overrides one of the company mapkeys, I'd tell them they either have to change theirs or not use the company mapkey (our company mapkeys aren't critical to use, they just make life easier).

[BenLoosli]

Do you have DM_REMEMBER_SERVER set to YES in config.pro or config.sup?

The trail file when starting Creo is doing something to disable Windchill, so it may not be recorded properly.

One method is to name all corporate mapkeys with the same letter or two, then the unique 1/2/3 character mapkey name. this will make the names longer, but insure that all of the corporate ones get loaded.

When I had remote access to users machines, I would examine their config.pro files and comment out lines that conflicted with the system mapkeys or options that we wanted to enforce, yet not put in config.sup.

Config.sup is not the place for any mapkey<period>.

[lhoogeveen]

DM_REMEMBER_SERVER set to YES as per Creo's default settings.

The corporate mapkeys method starting with a unique character will work initially... maybe it's me but Creo is quite good at dumping many settings and mapkeys into a users config.pro when changing just one setting from within Creo and save the config.pro from without Creo (I always edit config.pro from a text file to avoid this). I regularly run into people config files that have ancient config setups from 5+ years ago. Eventually, we'll want to update the mapkeys (e.g. when Creo 4 comes out) and our new mapkeys will lose to their old versions. Maybe it's just a training thing about keeping your personal config.pro clean but people aren't usually very good about that.

[BenLoosli]

When any of my users complain about a mapkey not working right, the first place I look is their config.pro. In some cases, I have cut them down to 20% of the original length because they had duplicate lines from saving changes and dumping all their in memory config settings to their config.pro.

It is an education process to get users to cleanup their files and other housekeeping tasks. I remind my users that fewer workspaces are better and try not to modify the same file in multiple workspaces. When doing a Windchill upgrade, I make them delete all of their workspaces and delete the local files behind the workspace cache.

[dgschaefer]

Creo's internal config editor is terrible.  I've seen user's config with multiple copies of our configs and theirs inside.

U've added these lines at the start and end of our configs to help sort this out:

!*** START DC CONFIG.PRO ***

!

[config options]

!

!*** END DC CONFIG.PRO ***

[Chris3]

I don't think you are going to find the perfect solution here. If a user wants to override the company mapkeys there is going to be a way to do it.

To piggy back on Doug's idea above the 3rd folder could be a network read only folder which would prevent users from changing the mapkeys. Users could always just change the start in location on the shortcut though (or launch Creo without a shortcut).

Another idea is to have a script that the shortcut launches prior to launching the Creo executable. The script could open the user's config.pro and comment out any mapkeys that are in the company config.pro. I would not advocate this though. There may be a valid reason for the user wanting to override the company mapkeys.

[lhoogeveen]

Christopher Rees‌

Agreed. There will always be ways to get around it but I was hoping to make it work for the average user.

I really like the network location idea but several plants all over NA and not all of them have spectacular internet connections so we generally have most Creo files local.

[BenLoosli]

With several plants, I would hope each one has a dedicated Windchill Replica server locally.

Put the mapkey files on each replica server and load them from there.

Do you run local installations of Creo or server them from a local server at each site. I run all of my users at 2 sites with a single network installation. Since the remote site is only 12 miles away we do not use a replica server.

[lhoogeveen]

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.

[dgschaefer]

CHRISTOPHER REES wrote:

... Users could always just change the start in location on the shortcut though ...

If your launch icon calls a batch file, the start in field in the shortcut is essentially meaningless as whatever the last directory navigated to in the batch file becomes the startup directory.  However, that does nothing to prevent this:

CHRISTOPHER REES wrote:

... (or launch Creo without a shortcut). ...

When I install Creo, I make sure no launch icons are created and part of our launch batch file is to copy our launch icons into their Start Manu.  Still not foolproof, but they have to work harder to get around our script.

[davehaigh]

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.

[lhoogeveen]

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!

[dgschaefer]

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.

[lhoogeveen]

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.

[TomU]

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".

[lhoogeveen]

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.

[dgschaefer]

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

[TomU]

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

[davehaigh]

I can assure you that you don't want any mapkeys in the config.sup. We figured that out in 1989 when we first started on ProE.

I have 3 lines in the sup. This should be a very small file. If you're putting everything including the kitchen sink in that file, you really limit your flexibility.

[lhoogeveen]

Here's a video showing multiple mapkeys in the config.sup working in Creo 3 M060. Notice how it disables my add ISO view mapkey from my config.pro (activated by typing ii) but multiple mapkeys from the config.sup work to change the open menu filter. Every mapkey I put in the config.sup seems to work... I've tested the first mapkey and the last mapkey in the config.sup to check for quirks. Now if they could just let mapkeys in the other config.pro's work in addition to this, admins would have a great tool for a standard set of mapkeys for all of their users if desired... And yes, the config.sup should contain very few settings (we have 3 as well).

[Chris3]

You could always create a product idea for that.

[lhoogeveen]

I just created the product idea for people to vote on:Allow Mapkeys in both config.sup and config.pro

[dgschaefer]

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.

[davehaigh]

The thing you need to consider is many of the corporate mapkeys are used in the ribbon file. So that brings up the issue of how do you make sure you have your correct system mapkeys for your system ribbon, and also allow your users to customize their ribbon.

So here is the other thing I do. I don't store the ribbon in the load point. This is because on our other network with no hard drives, I don't want to wipe out the ribbon if I load a new maintenance build of Creo on the server. Also I want to use the same method on both networks,  So in my startup script I have these lines:

These are from our network where the computers do have hard drives and Creo is loaded normally on the C: drive.

1. rem ** Put the ribbon file in place
2. echo f|xcopy "L:\configs\ribbon_wci\creo_parametric_customization.ui" "%USERPROFILE%\pro\Creo_2_home\cache\PDMLink_Cache\PTC\ProENGINEER\.Settings\creo_parametric_customization.ui" /y /r
3. echo y|copy "%USERPROFILE%\pro\creo_2_home\configs\creo_parametric_customization.ui" "%CD%\creo_parametric_customization.ui"  /y /r

In this case

• L: is the network share
• I copy the system ribbon to the cache instead of the loadpoint. The location as you can see from the command is in the user profile under the users start in dir. which in this case is Creo_2_home.
• %USERPROFILE% is on the users C: drive (local disk). On our other network this would be H: drive their netapp home dir.

I actually have a startup script for customizing the users ribbon. It doesn't load any ribbons. This allows them to make a clean ribbon and then store it in their configs folder.

If your going to do this you need this config option:

• load_ui_customization_run_dir yes
  • This allows Creo to read a .ui from the run dir.