Skip to main content
L
lhoogeveen17-Peridot
17-Peridot
June 29, 2016
Question

Corporate Mapkeys - Superseding User Mapkeys

  • June 29, 2016
  • 4 replies
  • 7875 views

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.

Normal.jpg Windchill Servers Missing.jpg

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

Windchill Sign In Missing in Trail File.jpg

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.

4 replies

D
dgschaefer21-Topaz II
21-Topaz II
June 29, 2016

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

    B
    BenLoosli23-Emerald III
    23-Emerald III
    June 29, 2016

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

    L
    lhoogeveen17-PeridotAuthor
    17-Peridot
    June 29, 2016

    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.

    B
    BenLoosli23-Emerald III
    23-Emerald III
    June 29, 2016

    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.

    Chris3
    Chris321-Topaz I
    21-Topaz I
    June 29, 2016

    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.

    L
    lhoogeveen17-PeridotAuthor
    17-Peridot
    June 29, 2016

    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.

    B
    BenLoosli23-Emerald III
    23-Emerald III
    June 29, 2016

    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.

    D
    davehaigh13-Aquamarine
    13-Aquamarine
    June 29, 2016

    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.

      L
      lhoogeveen17-PeridotAuthor
      17-Peridot
      June 30, 2016

      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!

      D
      dgschaefer21-Topaz II
      21-Topaz II
      June 30, 2016

      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.

      Terms & ConditionsAccessibility statement