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

Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X

Launch script for creo 1.0

visu
1-Newbie

Launch script for creo 1.0

Hi folks

I have downloaded the document of launch script from PTC community.

in that sample simple script was there i excuted that simple script. But no use could anyone can help me please?

I have attached my script (.bat file), please review it and help me.

I am dam stuck.

Thanks and regards

Viswanathan.K

1 ACCEPTED SOLUTION

Accepted Solutions

Hi Viswanathan,

I apologize I couldn't respond to your email sooner. I'm in a tough spot this week and it's very difficult to carve out time to reply to PTC Community messages. I did take a look at your launch script.

First... this is the worst launch script in history. It doesn't actually do anything. I'm just giving you a hard time- I know it's not your script.

Your problem is actually not that difficult. You're setting a variable to the place where Creo lives- and then running the parametric.exe file from that location. That means your error is either in the setting of the variable... or the call statement. In this case, I think you've set the variable incorrectly. On your last file, you added a backslash to your variable name and then repeat it in your call statement. This alone will stop the script from working.

Just to make sure there's not something else going on... let's just comment out the variable line and make a new call statement that includes everything. If it runs with this modification, then it should run with the variable corrected. Try this for the script:

@echo off

:: Set Environment Variables

:: set proe_load_point="C:\Program Files\PTC\Creo 1.0\"

:: Launch Pro/ENGINEER

call "C:\Program Files\PTC\Creo 1.0\Parametric\bin\Parametric.exe"

@echo on

exit

Note that only the bold line is actually doing anything. If you try it, does this work? If so, your problem is in the variable as I suggested above. If not then maybe there's something else going on. Let us know what happens...

Thanks!

-Brian

View solution in original post

21 REPLIES 21
TomD.inPDX
17-Peridot
(To:visu)

Echo back the string for the variable you defined. See if it truncated at the 1st space character. You might need to enclose it in quotation marks.

Dear Antonius Dirriwachter

I have attached the script i modified and run as you said, but app crash saying now. what should i do?

I have attached modified script and and screen shot of error.

Kindly review it and help me.

To sort it out.

Else you advise me how to create basic script. attach me document.

And have another question should I add any other in environment variables (variable name & variable value on user or system).

12.JPG

Thanks&regards

Viswanathan.K

TomD.inPDX
17-Peridot
(To:visu)

I guess that wasn't it... but if you look at your script, I suspect you have 2 backslashes when you joint the variable with the path:

@echo off

:: Set Environment Variables
set proe_load_point="C:\Program Files\PTC\Creo 1.0\"

:: Launch Pro/ENGINEER
call %proe_load_point%\Parametric\bin\Parametric.exe

@echo on
exit

C:\Program Files\PTC\Creo 1.0\ + \Parametric\bin\Parametric.exe =

C:\Program Files\PTC\Creo 1.0\\Parametric\bin\Parametric.exe

Also, Parametric.exe is actually parametric.exe ...not that this should matter.

Try removing the quotes and correct the double backslash

Check your work by typing "SET" at the command prompt and see if it shows a valid path. (comment out the "call...")

Dear Antonius Dirriwachter

I am very sorry to disappoint you and apologise me for my bad script as (Mr. Brain said) , I am on scratch level of making script, please guide me. I am going to try next level script.

Please guide me.

Thanks&regards

Viswanathan.K

TomD.inPDX
17-Peridot
(To:visu)

No need to be sorry, Viswanathan. I use to program many years ago and I am very happy that I do not need to do this any more. I am certain you have a good reason to use this script. I hope you can make it work as expected.

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!

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

Viswanathan.K

Hi Viswanathan,

What would you like to achieve with your script. I've got a ton of experience writing and tweaking startup scripts. What would you like to do with them? If you don't need to do anything special, you can just use the standard files that come with Creo. They only start to come in handy when you need to do something special.

For instance, at my job, we have a "company-wide" config.pro and config.sup file that's maintained by me and the other support administrators. We needed a way that we would make a change and have it instantly "pushed out" to all users without having everyone loading Creo off a single server. By using a startup script, we're able to put those files into the hands of our users each time they launch Creo.

We have expanded our startup script so that we can now offer upgrades to users when they launch Creo. If they're not running the latest version, they can be prompted to upgrade. We haven't deployed this yet but it's an example of what you can do with a startup script.

What particular things would you like to do? I'll be happy to help.

Thanks!
-Brian

Hi Brain

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

1.Assigning project

2.Assigning library

3.Assigning Templates

4.Assigning linestock file

5.Assigning configuration related to project

6.Assigning sonfig.sup

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

Viswanathan.K

Brian,

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.

 

Regards,

Manjunath

Hi Manjunath,

 

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?

 

Thanks!
-Brian

 

Thanks Brian. You answered my question. But Iam curious to know where are the config files located in your users computer and how you are able to use the script to maintain the latest configs for them. If they are not in the installation directory, then the users themselves can modify the files....

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:

 

C:\users\bob_jones\ENG_APPS\PTC

C:\users\bob_jones\ENG_APPS\SolidWorks

C:\users\bob_jones\ENG_APPS\Ansys

...etc...

 

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

 

Good luck! 🙂

-Brian              

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.

 

Annoying.

 

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.

 

 

BenLoosli
23-Emerald II
(To:dschenken)

Was Toby pushed or did he jump ship? That will be the Friday question for today.

 

Brian, Very well explained. Thanks for your detailed explanation. Now I need to see if I can convince my Global IS to install Creo out of Program files...which Iam not sure I will be successful. Let me give a try. and Yes, PTC's new community is a nightmare...and I see there is a very low participation from the members due this reason....

Hi Viswanathan,

I apologize I couldn't respond to your email sooner. I'm in a tough spot this week and it's very difficult to carve out time to reply to PTC Community messages. I did take a look at your launch script.

First... this is the worst launch script in history. It doesn't actually do anything. I'm just giving you a hard time- I know it's not your script.

Your problem is actually not that difficult. You're setting a variable to the place where Creo lives- and then running the parametric.exe file from that location. That means your error is either in the setting of the variable... or the call statement. In this case, I think you've set the variable incorrectly. On your last file, you added a backslash to your variable name and then repeat it in your call statement. This alone will stop the script from working.

Just to make sure there's not something else going on... let's just comment out the variable line and make a new call statement that includes everything. If it runs with this modification, then it should run with the variable corrected. Try this for the script:

@echo off

:: Set Environment Variables

:: set proe_load_point="C:\Program Files\PTC\Creo 1.0\"

:: Launch Pro/ENGINEER

call "C:\Program Files\PTC\Creo 1.0\Parametric\bin\Parametric.exe"

@echo on

exit

Note that only the bold line is actually doing anything. If you try it, does this work? If so, your problem is in the variable as I suggested above. If not then maybe there's something else going on. Let us know what happens...

Thanks!

-Brian

And Tom beat me to it!

Dear Brain

I am extremely sorry to make worst script, i am scratch on this script mr. Brain.

and thanks brain your script is working. Now am going to try next level please guide me.

Top Tags