I was only teasing. I'm a bit punchy after 9 hours on a plane cramped into the corner seat.
I'm pretty sure your message pinpointed the problem ... I think it was the double backslashes!
I am much pleasure to say about my script and why I need that.
We have customers worldwide, we are working in different projects, with different setting files so I analyased about launch script from another software in my office, so I planned, why not in pro-e? And started to working with that few months ago.
Actually I finished my B.E.Mechanical Engineering on 2012, and past 1 year am working in an a MNC network, i am child to working field and am trying to develop myself anything new, Because always knowledge is wealth, May script was found earlier, but now only am working on it due to lack of my knowledge.
Why i said this above short story, to know you that i am kid on working field.
Let me come to point,
That i have an basic idea of my script, May be you already well known think so after you reading my scripting idea.
Actually in script i need somethings to be default like
4.Assigning linestock file
5.Assigning configuration related to project
7.Assigning Working directory.
8.Assigning config.dtl file
9.spliting floating license to user.
10.Deleting trail file,purge, .inf,,.SEQ file, XML documents,.idx,.m_p file.
that's it. i need to create script like this Mr.Brain. If you have any example of basics about scripting for pro-e, Please mail me to this id -
Thanks & regards
Hi Antonius Dirriwachter
I have said about one of my launch script , please view it and help it out. is't possible or not?
Thanks and Regards
I have the same requirement as you have done in your company.
If possible could you please share your script (simplified)
I have created a basic script that works only on my computer but to push this to other users, the configs need to be copied to the installation directory for which they dont have access and iam not sure how to address this admin login issue with the script.
Unfortunately there's no way to copy config files into the installation directory if they don't have write access there. The only other options are to have a script executed automatically by some authorized account to perform the copy process.
For example, some companies have robots like Dell KACE or other software which can perform automated administration tasks with elevated privileges on the client's workstation. This kind of automated software running with elevated privilges could copy the config file into the installaiton directory.
Otherwise, you're stuck copying the configuration files into either the users' HOME directory or WORKING directory. As you probably know, when Creo starts, it reads the config.pro (and config.sup) file from the load point (installation directory). It then also searches the user's HOME directory (Windows profile "home" such as C:\users\username and then finally the user's current WORKING directory for additional files.
You may be able to copy the config files into the users' HOME directory - however, this might overwrite any customizations they'd saved in that location. One option might be to merge your configuration file into any file they've created. Perhaps append your file to theirs... or append their file to yours?
I'm not sure if I'm answering your question - but hopefully this gives you some ideas?
There are a few ways to approach this problem - and depending on your users, your organization, and your personal philosophy for maintaining your environment, you can pick and choose what suits you best.
I don't know how to organize the response so I'll just try to group my thoughts:
You're correct, if you write the config files to the users' HOME or WORKING directory, they can change them. But this may not be a big deal to you.
Once upon a time, config.pro settings and mapkeys were universal. Experienced users customized the heck out of their environment to achieve efficiency. Nowadays, most people just futz with the colors or a handful of settings they care about - and ignore the rest. Mapkeys are much less common. Therefore - you may have less to worry about since the newest user's often ignore the config files completely.
Still, you're correct... the users can change the configuration files in their HOME and WORKING directories. Then again - MANY USERS can also change those same files in the Creo Loadpoint! The reason they don't - is because they don't know where those files are! If you polled 50 everyday Creo users, I'd bet 49 of them (maybe all 50) wouldn't know the loadpoint config files are located in the <Loadpoint>/Common Files / Text folder. Seriously, most people don't know what you mean by "loadpoint" in the first place. Expert users MIGHT know.
The point is - many times users can access the loadpoint config files. If they knew where they were, they could edit them. The files are really only protected by the fact that many people can't find them to mess with them!
In my enviroment (rather, my "old environment" at NASA), we did not install Creo into the normal C:\Program Files directory structure. We installed the software into each user's profile. We stored all engineering tools into the user's profile - because C:\Program Files was protected. User's required elevated privileges to write into that area and requesting and assigning those privileges was a chore. Instead, all engineering software went into C:\users\<username>\ENG_APPS. So there'd be:
Down inside those folders, the users had all privileges and could easily change the config.pro/config.sup files... but they never did. Most people didn't know where to find them so they never altered them.
We were protected one other way, too...
The script which copies the config files ALSO launches Creo. The user double-clicks an icon on the desktop which fires off the script. The script copies down the config.pro and config.sup file from a shared drive (or protected network folder). The user DOES NOT have access to alter the files on the shared drive or protected folder. The files are copied into the Creo loadpoint (into the C:\users\<usernamne>\ENG_APPS\PTC\...\Common Files\Text folder). And immediately afterward, Creo launches. The user has no time to edit the file - because Creo is already launching and reading it.
If the user edits the file in the loadpoint and changes it, his changes are discarded the next time he/she starts Creo. The script overwrites their changes with the file copied from the network. They can change the file 100 times... and 100 times their changes are overwritten. Unless they're very sharp, they cannot avoid using the standard configuration files.
Yes, there are ways to defeat this. Again, most people will never complain. You'll get a few jokers who try to game the system but they'll often give up after the first few times their changes are overwritten.
So there you go... a bit of trickery goes a long way. You're protected because the files are usually hidden. Most people can't find them. And, if they do, use your script to automatically discard their changes. If you have some really stubborn people, there are additional steps you can take. If you want to get really draconian, you can force everyone to run Creo from the network - then they CANNOT change the files at all.
Over the years, many companies have tried to install Creo ONCE somewhere out on the network. Users launch the application from this network location - because it is NOT installed locally on the users' workstation at all. This works but is typically either slow, very slow, or UNGODLY SLOW to launch. Once launched, it's usually fine. Every time I've seen this tried, the company eventually gives up and installs the software locally.
I'm sure somewhere out there you'll find a large company who insists on having ONE version of Creo running off the network... but usually this is only done in very small installations.
Anyway - I hope that helps! Who knows... I've had two 24 oz. cups of coffee and about 2000 mg of B-vitamins. I'm wired like a cat on an electric fence...
And wait wait wait...
What's this LEVEL 10 stuff? Level 10?
Grrrrr. Every other year we get a new PTC Community. With every new PTC Community, we toss out whomever used to be in charge and bring in someone new. Each time, the system changes, the levels change, badges go out the window, and the interface gets worse.
And geez is this new text editor crappy or what?!
They made the change and then tossed the guy out - or he escaped. Just part of monetizing and gamifying product support.
You must have missed the "Super Enthusiast," and the like, labels they had before the numbering scheme.
Yeah, I'd like to say I'm surprised - but this is always how it works.
I think this is the third or fourth incarnation of this message board. Gamifying is all well and good for people that like contributing for badges and awards. But gamifying the system... and then scrapping the game and restarting it every 2 years is frustrating.
One gets the idea the focus is not on support, collaboration, and content as much as it is about flash and inconsequential fluff.