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

Force the user to use only one config.pro file

dparasuraman
1-Newbie

Force the user to use only one config.pro file

Hi,

I would like to restrict the users to use only one config.pro file which is standrad. Currently the users can export and then import multiple config.pro which leads to many standard issues.

Could any one help in either locking the export/import option or forcing the user to use only one file at a time.

Thanks in advance

Dhamodharan


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.
1 ACCEPTED SOLUTION

Accepted Solutions

Hi,

use config.sup file. This file contains configuration options which must not be changed by user config.pro files.

Martin Hanak


Martin Hanák

View solution in original post

7 REPLIES 7

Hi,

use config.sup file. This file contains configuration options which must not be changed by user config.pro files.

Martin Hanak


Martin Hanák

View solution in original post

Do you search directories for "config.sup" to see if there are any on the network or local hard drive?

llie
14-Alexandrite
(To:dparasuraman)

Martin is correct. The config.sup is used for configurations that the user cannot override with their own.

This is very useful for pushing out company standards and search paths.

BenLoosli
22-Sapphire III
(To:dparasuraman)

Config.sup has drawbacks, too.

You can only define 1 mapkey in a config.sup.

In fact, any command that can be set multiple times, layer, mapkey, etc, are a problem for config.sup.

There really is no way to prevent a user from creating their own config.pro file in their start-in folder and having Creo read it. You can do tricks with batch files and maybe delete any config.pro files found in the start-in folder before launching Creo, but that is not the intent of config.pro files.

Config.sup is set and read at system start up with settings that the company admin does not want the users to change.

Config.pro in the <loadpoint>/text folder is read at start up with company wide settings that are the preferred for you company.

Config.pro in the start-in folder is for loading settings the user has found make their life easier when using Creo. These include Mapkeys and some environment settings.

config.pro is a shortcut to make changes to config options through the UI. Even if you make sure there is only one source for the config, users are still able to change any option that is not set in the config.sup. Unfortunately multi-value options like mapkeys and def_layer can have one and only one value set in config.sup.

The questions are, why do you think users are making these changes and why are the users are making these changes. These are not technical problems, but require a change in your organization.

I thank every one for your useful inputs, I agree with most of the points suggesting the usage of config.sup and also that the users should not be changing the options unnecessarily and requires change in the organization.

Unfortunately different group of users have differnt their own config.pro which creates defects as the standards are not maintained.

Hence the organization is looking for any option to disable the import button in Confguration Options

Be careful in what you put in your config.sup. You really don't want to lock users out of making any changes to Creo. You want to control only the options that affect the quality of your data. Many options are user preference (system colors, are planes displayed or not, are datum tags displayed, mapkeys, etc) and you want users to configure their system to what works for them.

Locking them out of everything is a recipe for unhappy, and unproductive, users.

I've managed our systems for 10+ years. We've got a config.sup with 20-25 lines in it, a company config.pro (preferred settings, company mapkeys, etc) and each user has their own config.pro. It works well.

--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn
Announcements