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

Community Tip - Help us improve the PTC Community by taking this short Community Survey! X

An Option in Config.pro to specify a separate file for Mapkeys

An Option in Config.pro to specify a separate file for Mapkeys

A highly customized Config.pro file can be confusing to manage and can become cluttered with duplicate entries - for both mapkeys and options.   An option to specify a separate mapkey file would make managing these files much easier.

This is even more important since the ability to have multiple sessions has been added.  This would enable using different config.pro files for different sessions and easily use the same mapkeys.

Regardless of the many possible post-installation work-arounds, this out-of-box solution would save a lot of (especially first time) users a lot of headaches.

11 Comments
NicolasBourgeoi1
13-Aquamarine

Whe use seperate files and concatenate them in login.bat

ECHO *** concatenating Config.pro + Mapkeys

COPY %CAOCONFIG%\config.pro "%COMMONFILES_INSTALL%\text\config.pro" /y >NUL
TYPE %CAOCONFIG%\mapkey.pro>>"%COMMONFILES_INSTALL%"\text\config.pro

sully7
13-Aquamarine

If you have access to one of the Toolkit API's, you can also do this through those.

For example, using the original Pro/TOOLKIT API, you could use the following to load as many as you want into the session, upon user_initialize()

ProInputFileRead(NULL,desired_path_w,PRO_CONFIG_FILE, NULL,NULL,NULL,NULL);

klozier
8-Gravel

This would be great for deploying enterprise standard mapkeys.  It would be better if there were controls to keep users from saving the mapkeys from a seperate file into their own config.pro with the save all command.  I would think some thing like a config.sup for mapkeys.  We see users with very large (e.g., long) config.pro files from copying all mapkeys in session.  This leads to slow start times and out of date mapkeys/mapkey conflicts.

STEVEG
21-Topaz I

We do this a different way.  But I like you version too.

copy /B /Y <loc>\config_base.pro+<loc>\config_1.pro+<loc>\config_2.pro <install dir>\text\config.pro

LawrenceS
18-Opal

Kelly Lozier‌, and a headache for actually helping users to sort through that cluttered config.pro.  TO be fair to the user, when saving the config.pro it is very intuitive to choose the wrong option of save all mapkeys in session.  PTC should really make the default for this action to append the config.pro with an appropriate button that makes it clear what the user is doing.

Although I agree with your idea, to me the bigger issues is this non intuitive saving.

SvenR
13-Aquamarine

another way:

type *.pro > "%CREODIRDATECODE%\Common Files\text\config.pro"

PTCModerator
Emeritus
Status changed to: Acknowledged
 
Jaime_Lee
Community Manager

A highly customized Config.pro file can be confusing to manage and can become cluttered with duplicate entries - for both mapkeys and options.   An option to specify a separate mapkey file would make managing these files much easier.

This is even more important since the ability to have multiple sessions has been added.  This would enable using different config.pro files for different sessions and easily use the same mapkeys.

Regardless of the many possible post-installation work-arounds, this out-of-box solution would save a lot of (especially first time) users a lot of headaches.

mneumueller
17-Peridot
Status changed to: Under Consideration
 
BenLoosli
23-Emerald II

I would like to see this implemented like Search Paths.

They can either be in the config.pro or point to a file that contains the mapkeys.

 

One other thing to consider would be multiple mapkey files and how to read them. Could the Mapkey_File_Path (my name for it) be in a config.pro multiple times, each one reading a different mapkey.pro file?

Aaron_Daniel
13-Aquamarine

Yes @BenLoosli

 
This is exactly as I imagined the implementation...if a Config contained a 'Mapkey_File_Path' (your good name for it - or perhaps just Mapkey_File), then it would read the external  file of Mapkeys.  Mapkeys that might already be in the Config file would be retained.  The external file Mapkeys that are unique would be added to the available Mapkeys.
 
A question arises about what to do with duplicate (un-unique) Mapkeys in the external file...should they be ignored...or should they override Mapkeys already existing in the Config?  Personally, I'm for the 'ignored' solution...this would allow a convenient way for administrators to maintain adherence to certain Mapkey standards, while enabling individuals or groups to easily add and maintain their own.
 
For a majority of users, Configs would contain no Mapkeys...so that all Mapkeys are established and maintained (edited) in the external file (separating them from the current messy environment of Config files).
 
Years ago I explored keeping each individual Mapkey in its own file (in my case suffixed with .mpk) and using a batch file to concatenate all the *.mpk files into a file and then concatenating that into the config.pro (like @NicolasBourgeoi1 indicates above).  This may sound like a great method - as you can save just individually created Mapkeys to a single file (and then rename them with the .mpk suffix).  This works well...until PTC issues a update that requires changing (manually editing) most of the over 400 Mapkeys I developed and depend on over the years.   In this case, it's best to have all the Mapkeys (or at least most) in a single file.
 
To permanently implement a manually edited Mapkey requires exiting Creo and restarting.  There needs to be a way to re-read the Mapkeys into a session without having to completely exit the program.  A separate Mapkey file/s would make this functionality easier.  But this capability will undoubtedly require submitting another new idea request.
 
I like the idea of being able to read 'Mapkey_File' multiple times, or perhaps a comma-separated list of files.  This would allow Mapkeys with similar functions to be nicely grouped and managed.
 
And all of this complicates (or at least affects) user interface modifications (for those that use mapkeys from the ribbon), but this can be managed reasonably with a little planning.
 
As a matter of note:  Mapkeys should not be thought of as just 1 or 2 or 3 key-hit shortcuts.  'Long-name' Mapkeys can be directly accessed from the ribbon, and can be called from within other Mapkeys.  Mapkeys (actually 'Macros') can be a powerful tool.  Nesting Mapkeys  can multiply that capability.