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

Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X

Question on setup for individual users (config.pro)

Patriot_1776
22-Sapphire II

Question on setup for individual users (config.pro)

As long as I've used Pro/E (17+ years), there was generally a company "config.pro" (and perhaps other files) and a separate user-customizable "config.pro" (and perhaps other files). The loadpoints were specified in a path statement, usually in a batch file. This allowed the company to set certain standards, yet allowed users to customize mapkeys and other settings that did not compromise the company standard settings.

Are people still doing this?

This is the way I've set up the systems here, and all the ex-Solidworks users are trying to tell me it's the "wrong way", and that it should all be networked. I'm trying to explain to them that having a local (C:) folder and a "config.pro" file that is specific to each user allows them to individually customize their configuration and performance, and it's falling on completely deaf ears. And that putting that on the network in a single file is pointless. Might as well then roll EVERYTHING into a company "config.pro" file and call it a day, but that means they' cannot customize anything. Or, if they want to customize things, then we need to clutter up our network drive with individual folders, and then have individual path statements in the "config.pro" to get to things like their syscol.scl, tree.cfg, and .dtl files. If it's in a local directory, say: "C:\FRANK\(C) PROE\(C) CONFIGS" then I need to only push this out once, and the paths always work regardless of them changing mapkeys or settings.

I think it's far easier to have the users have control their own files at the local level, than trying to do it all at the network level.

Thoughts?


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

The only things you can't customize are the ones in the config.sup. You can open any file you like that has valid config options. I rename mine with a .txt suffix so that Notepad can more easily be used to edit them.

Most places I've been (both) have a batch file that copies the company config.pro to the loadpoint, though I think one can set up the entire loadpoint to be on a network drive so everyone is lock-stepped to the same release and everything.

I wonder why they care.

Patriot_1776
22-Sapphire II
(To:dschenken)

At other companies we had the company config.pro on a network drive with read-only acces for most users, except me as the admin. Then the local files they had access to.

My friend/coworker just objects to having my name on his computer! LOL

We do that here, but all the config files live on the server. That way we have access no matter what computer we are using. I may take a shared laptop into a meeting room, or in some cases we have a dedicated workstation in the room that I log into. Having my configs on the server means that I get them no matter where I log in.

We have a bit of a unique situation in that we have company configs, user configs and client configs. Here's how we do it.

  • We have a shared drive mapped as P: for all Proe (now Creo) users. Our configs, start models, reference material and more all live here.
  • At launch, our company config files (config.sup, config.pro, config.win (WF5 and older) and creo_parametric_admin_customization.ui (Creo1 +) are copied from the server into the local loadpoint/text folder via batch file.
  • We then launch Proe/Creo in the user's config folder on the network so that their config.pro/config.win file loads. The user's creo_parametric_customization.ui file is a bit trickier, it has to be local, so it is and we have a scheme to update the server as needed.
  • The user saves their other config files (model tree config, system colors file, etc.) in this folder too and sets the appropriate options to point to them.
  • We then run a mapkey after launch to load a client config file, if one exists. This is actually automated by a choice in the launch batch file and a trail file that includes the mapkey.

SW has nothing like this for managing company standards and user preferences on the fly. The best you can do is set everything at install, but nothing is there to maintain this. It's important to us to set a small number of things to maintain consistency in our models. Things that don't change the model we leave up to the user.

I hope that helps.

--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn
Patriot_1776
22-Sapphire II
(To:dgschaefer)

All input helps, thanks!

Yeah, I figure to have an environment where EACH individual user can configure his system to exactly the way he wants it, there either has to be a separate, unique folder that is local (C:), or networked (W: in our case). And if everyone insiists on naming their folder whatever, then there's a bunch of work to do to make sure the config.pro file points to that special directory. It has to be named something, local or network, I don't see an issue labeling it "FRANK" vs "user", especially since it means less work.

Ah well. That's what you get when you have SW people try and tell you how to run Pro/E!

I user the user's login name as their folder name, that way it's easily available to me for use in my batch files.

--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn
Patriot_1776
22-Sapphire II
(To:dgschaefer)

Right, but then I'd need like 10 different folder names, or be forced to go back thru the config.pro and change the path and then make sure their foldernames that got created matched the names. This way I just copy the folder C:\FRANK\(C) PROE\(C) CONFIGS to their PC and it's done.

Am I missing something?

cprice
6-Contributor
(To:Patriot_1776)

Frank,

I just saw your reply - the way to get around using 10 different user names in your paths is to add an environment variable called

%USERNAME%

to everybody's computer and have the username be the Value (mine would be cprice)

I've done this for years.

We use a similar setup as Doug described. The difference is that user configuration files are stored in the user home directory. This is the directory pointed by %HOMEDRIVE%%HOMEPATH% combination of environment variables. The home directory is on a network drive so is always available regardles what workstation we are using.

I'm not sure if this will work for the user's creo_parametric_customization.ui file as we just preparring to migrate to Creo 2. I think I'll find out soon.

You can use variables in config files. For example, this is my path for our company model tree config file:

mdl_tree_cfg_file P:\config\00_design_central\config_files\$proe_ver\dc_tree.cfg

$proe_ver is my variable for what version of Proe was launched.

--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn

That's interesting Gabriel. We don't tend to move one user around to different PC's though. Also, in naming a particular drive locally the same as everyone else's, if we do, the files are always in the same place. Interesting idea! That might also allow me to push out changes easier. Hmmm....

Frank,

You are right. In normal circumstances we don't move the users from one PC to another. On another hand, situations when we need to start Pro/E on the conference room computers or on the shop are relatively common.

Doug,

I was wondering myself if using variable names in config.pro is still working in Creo? Can you confirm if this is the case? Thank you.

Yep, I use them in WF4, WF5 & Creo2. We never used Creo1, but I had it all set up and it worked there too.

--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn

nice techniques

Top Tags