Skip to main content
D
dparasuraman1-Visitor
1-Visitor
April 20, 2015
Solved

Force the user to use only one config.pro file

  • April 20, 2015
  • 5 replies
  • 2245 views

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.
Best answer by MartinHanak

Hi,

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

Martin Hanak

5 replies

M
MartinHanak24-Ruby IIIAnswer
24-Ruby III
April 20, 2015

Hi,

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

Martin Hanak

Dale_Rosema
Dale_Rosema23-Emerald III
23-Emerald III
April 20, 2015

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

L
llie17-Peridot
17-Peridot
April 20, 2015

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.

B
BenLoosli23-Emerald III
23-Emerald III
April 20, 2015

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.

D
dschenken1-Visitor
1-Visitor
April 20, 2015

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.

D
dparasuraman1-VisitorAuthor
1-Visitor
April 21, 2015

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

D
dgschaefer21-Topaz II
21-Topaz II
April 21, 2015

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.

Terms & ConditionsAccessibility statement