Allow Mapkeys in both config.sup and config.pro

[lhoogeveen]

The config.sup is for settings that users (or any other config.pro files) are not allowed to change in Creo and seems like a perfect place for corporate wide mapkeys to create standard processes/toolsets. In Creo 3 M060 as shown in the attached video, the config.sup will allow MANY mapkeys to exist in a Creo session but not let ANY of the mapkeys from the other config.pro files (e.g. a users config.pro) load into Creo. It would be way more flexible if the other config.pro mapkeys would load into session as well. Where two mapkeys have the same name, always use the config.sup mapkey. General user config.pro files often tend to get tons old settings and mapkeys built up over time if edited from Creo so superseding user mapkeys where a naming conflict exists help admins keep users using the latest and greatest processes/mapkeys as things inevitably change.

Several good ideas were shared in Re: Corporate Mapkeys - Superseding User Mapkeys about how to accomplish this but currently require a lot of monkeying around or restructuring of config setup locations to somehow load the desired corporate mapkeys last. The idea above would make this way easier.

[jfojtik]

I voted this down. End users should always be in charge of the mapkeys.

An admin can use APIs to modify the end user's environment as the company sees fit.

[lhoogeveen]

Just like the config.sup should have only a handful of settings, the config.sup should contain a small set of mapkeys to keep standard tools up to date. I just cleaned a user's config.pro that had 2838 lines of junk in it down to 127 lines. The bloated config.pro had many different revisions of the same mapkeys with some dating back to 2010. Some of those mapkeys are our standard way to create things like DXF's. I would say this terrible config.pro management is more the norm than not for an average Creo user. In specific cases, admins should be able to say the DXF mapkey tool works across everyone's machine in a standard way that can easily be updated. API's are overkill for for something as simple as making sure DXF's have the correct settings checked as they're saved. If users want their own DXF mapkey, they could call it PDXF or anything else instead of DXF.

[lhoogeveen]

Also, implementing a solution using an API would do nothing to prevent users from using the old mapkeys floating around.

[TomU]

jfojtik wrote:

I voted this down. End users should always be in charge of the mapkeys.

An admin can use APIs to modify the end user's environment as the company sees fit.

This seems like a very narrow view of the many different organizations that use Creo.  I don't know of any small to mid-size businesses that are using the API's to customize anything.  The barrier to entry is simply too steep.  (Toolkit is expensive and small companies just don't have the resources to dedicate to customization.)  All of these same companies ARE using mapkeys and config.sup files.  It seems like it makes perfect sense to at least offer this capability as an option.

[dgschaefer]

Having this option available doesn't mean you'd have to use it in your organization.

For myself, I wouldn't see putting many mapkeys in the config.sup, perhaps none.  but I can imagine wanting to streamline standard practices and using mapkeys to both enforce them and ensure consistent use.  In such a case, I'd want to be able to make sure that a given mapkey could not be overwritten by the user.

[StephenW]

I agree that mapkeys, in general, should be left to the user but I can see a lot of benefit for a company to provide a set of mapkeys along with some standard icons or custom menu items for those mapkeys to do certain operations to help align files with company standards and consistent practices.

Outside of the scope of this idea, from a user standpoint, I would expect the company provided mapkeys would not take up the 1 or 2 or 3 letter/number combinations that users would want to use for user defined mapkeys to help them improve the performance of their daily work.

[jfojtik]

hi Lucas,

Sorry that my reply comes this late. I don't use this account frequently because, as i still work for multiple companies i tend to use my main account, which is outta maintenance and accounts without maintenance can't vote for ideas. If you are willing to learn J-Link and solve your issue as administrator i'm willing to help. Just pm me to my main account if you need any help.

As a former harcore user of Creo Parametric, now Creo Parametric and Windchill admin, I consider mapkeys and relations to be vital low-level automation tools that should serve only the end userbase. If the userbase doesn't specifically want the admin to abuse/alter these simple automation tools then the userbase should have all freedom to re-define the way these are set the way they want to. Even the freedom to mess it up and realize they do it wrong on their own.

At my current employer we do have mapkeys with shortcuts like aa, tt, ac, but we do not have any hardcore user complaining that they would like to have their own setup. If I was at that rank I'd complain about this admin's setup all days till it'd be gone. Simply put people here have predefined stuff so they don't tend to figure out how to even setup mapkey or anything. That alone leads to the software not being developed by the end userbase and not being used in it's full potential. Also with this trend there aren't going to be any hardcore user arising from this userbase. In my view this kind of implementation is just wrong.

Thanks for starting this interesting conversation.

~J

[gleonard3]

We have standard ribbon buttons that are driven by mapkeys that we push to the entire implementation.  By not being able to lock these specific toolbar mapkeys down with the config.sup, users are in danger of saving them in their personal config.pro's when they decide to save all mapkeys.  At that point they're immune to any tweaks we may make to these standard commands going forward.  Not good.

[BenLoosli]

I think PTC has solved the issue of writing all config settings to the user's local config.pro file. Only changed settings get written back to the config.pro.

[Chris3]

I think PTC has solved the issue of writing all config settings to the user's local config.pro file. Only changed settings get written back to the config.pro.

---

When did this happen?

[gleonard3]

We're on 7.0.8.0, and users are inadvertently saving ALL mapkeys to their personal config.pro's.  

[BenLoosli]

They are doing it wrong then.

When you make a change in Creo to the configuration file and press OK, you get this dialog box:

If you press Yes, it will save only what is displayed in the current configuration window to a file of your choice, default is <working directory>\config.pro. 

If you press No and then go back and do an Export Configurations (Notice the 's', plural), you get a new config.pro with ALL of the configuration settings loaded in your Creo session.

If you press No and then go back and do an Options: Inport/Export, Export per current filter, you get only the current displayed configuration settings, but the file is unformatted.

[TomU]

Regardless of how saving works, it would still be helpful to be able to define company mapkeys that could not be overridden by the users, intentionally or unintentionally.  Today the only settings protected are those in the config.sup, and that can't contain mapkeys, hence the product idea.

[gleonard3]

We have literally thousands of users.  If there's a way to do it wrong, despite all warnings, there WILL be a subset of users who WILL do it wrong.  That realization is a way of life in this support business.  Keeps it interesting.  The ability to lock specific mapkeys down in the config.sup would mitigate that,  Now, how difficult, or possible, that would be to get done in the software is a matter for PTC.