Saving my settings with a new install of Wildfire...

I believe this has been covered, but here goes...

1) The startup directory can be specified (on MS Windows) machines by defining a 'start in' directory path in the Windows shortcut.

2) The config.pro option for the system colors file should be something like: system_colors_file U:\pro24\syscol.scl

use the explicit directory locations for the file (mine is located in U:\pro24)

3) Keep the browser from opening during startup by selecting the following menu options:

Tools | Customize Screen

select the tab 'Browser'

unselect the box 'Expand browser by default when loading Pro-E'

save this in your config.win file (make sure that this is in the startup directory)

Also, go to

and download 'config.pro mentor' this will list all of the config.pro and x.dtl options

Lastly go to

for one of the best sites for pro-e setup information.

PS, as aside, I use the w> I've just installed Wildfire on a new machine, and I'm going crazy

"Chris Gosnell" wrote in message news: snipped-for-privacy@corp.supernews.com... : I believe this has been covered, but here goes... : Ah, Chris, you are a master of understatement! Must be that a bunch of people has decided that the world isn't coming to an end and it's time to spend some money. On Pro/e software, is my guess. Thanks for getting this all out. There probably ought to be an FAQ on this stuff.

: 1) The startup directory can be specified (on MS Windows) machines by : defining a 'start in' directory path in the Windows shortcut. : : 2) The config.pro option for the system colors file should be something : like: : system_colors_file U:\pro24\syscol.scl : : use the explicit directory locations for the file (mine is located in : U:\pro24) : : 3) Keep the browser from opening during startup by selecting the : following menu options: : : Tools | Customize Screen : : select the tab 'Browser' : : unselect the box 'Expand browser by default when loading Pro-E' : : save this in your config.win file (make sure that this is in the startup : directory) : : Also, go to

and download 'config.pro mentor' : this will list all of the config.pro and x.dtl options : : Lastly go to for one of the best sites for : pro-e setup information. : : PS, as aside, I use the windows shortcut to point to a startup directory : that has all of the options (config.pro, x.dtl, config.win, syscol.col) : files I need. I then launch pro-e to this directory. One in Pro-E, use : the file tree to point to a directory for your project. Right click on : this 'file folder' and select 'Set Working Directory' pro-e will not : work out of this directory. :

Maybe just one more that people might want to save ~ the way they've set up thier model tree. The 'Settings' button at the top lets you save the way you've set it up. But, as with most configuring in Pro/e, that's just the start. You also have to go to config.pro, find an option name that says mdl_tree_cfg_file. Either manually enter the path of the tree.cfg file or browse to the location. Oh, yeah, and color.map/color.dmt files should go here also.

Another PS: template files or start parts which default to /templates ~ edit the existing ones or copy and create your own so that they contain consistent information like parameters, units, views, layers. Set which will be used by default with config.pro options like template_designassem, template_solidpart, template_sheetmetalpart. These files can be kept anywhere, just browse to the location.

David Janes

Thanks for the help guys, and I apologize for my haste. I should've done some searching, which is what I did right "after" I posted. I seem to have solved all my problems with one exception. I can't seem to find a way to save the "Environment settings. I don't care to have a lot of icons around, especially if I don't use them very often, so I don't want to keep things like Datum Point Visibility in my toolbar. I want to be able to turn them, and other things, off initially...

I'll look through the links you've posted, hopefully there'll be more answers in there...

Again thank you very much, and one more sorry for not searching first...

I agree. Here are some of my options (for example) to make life in pro-e easier:

datum_display NO datum_point_display NO datum_point_tag_display NO display_coordinate_sys NO display_full_object_path YES display hiddenvis edge_display_quality VERY_HIGH fasthlr no hlr_for_quilts no menu_show_instances NO sketcher_refit_after_dim_modify no smooth_lines yes spin_center_display NO spin_rate_zoom_sensitive no spin_with_part_entities yes spin_with_silhouettes no

There are other options you may want to enable such as 'prompt on exit' or 'retrieve_data_sharing_ref_parts', but it depends on your particular needs, and how you expect pro-e to work.

closer9 wrote:

: There are other options you may want to enable such as 'prompt on exit'

I thought this might be useful, too. But, as Pro/e is not a Windows program and has neither the intelligence nor the good manners to tell you that you have unsaved data before you close the program, this prompt can lull the naive into a false sense of security. If you answer it's prompt with a Yes and convince it that you really and truly and sincerely do want to close the program, it will happily trash your data for you. This is the Unix way.

David Janes

Thank God. When I tell a computer to do something, that is EXACTLY what I want it to do. If I am stewpid enough to ask it to do something dumb, so be it.

However, a computer which does exactly what *I* tell it also does *not* do what I *don't* tell it to do .... can we say "worm" ? Virus ? Spyware ? "Direct" you towards certain products by purposely making life a living hell if you try to use a competitor's software ?

Actually, your complaint is not against Unix. It's the window manager or desktop or shell or whatever you want to call it which creates these behaviours. I doubt that you're objecting to the superior file systems or better multi-tasking or cleaner organization or better scalability that comes with Unix - you just dislike the X-Window system and the geeky behaviour of the various shells - or what you've heard about the various desktops :-)

Try Irix. Probably the nicest compromise between user-friendly and geekster-powerful that you'll find. Unfortunately, the hardware to run Pro/E fast on an SGI is not cheap. But neither is a 275GTB ....

-snip-

-snip-

Excuse me for the dumb question, but I am somewhat confused. Are you saying that Pro-E will not save updated models in session when you exit?

In my example, I do die and mold work. The model drives the die cavity in the die, and the die cavity drives the EDM electrode. There are drawing sheets for all of these components and I often have

6-8 inter-related parts/assemblies 'in session' including family table instances of components/assemblies. 'Prompt on exit' SEEMS to save anything that was changed in session.

I also have have the following options enabled to help propagate the model / drawing / assembly changes:

propagate_change_to_parents yes retrieve_data_sharing_ref_parts yes save_objects changed_and_specified

I would appreciate your comments on the suitability of these options to keep all of the file dependencies 'up to date'.

The only other way I know to make sure that the files are up to date is to only open one at a time in the order of the feature association part>die>electrode, then close and save all of the parts and open the associated drawing sheets one at a time.

Being a prior Solidworks user, I was constantly having problems with Pro-E until 'prompt on exit', and the other options I selected as listed above.

"Chris Gosnell" wrote in message news: snipped-for-privacy@corp.supernews.com... : : : David Janes wrote: : -snip- : > : There are other options you may want to enable such as 'prompt on exit' : >

: > I thought this might be useful, too. But, as Pro/e is not a Windows program and : > has neither the intelligence nor the good manners to tell you that you have : > unsaved data before you close the program, this prompt can lull the naive into a : > false sense of security. If you answer it's prompt with a Yes and convince it that : > you really and truly and sincerely do want to close the program, it will happily : > trash your data for you. This is the Unix way. : >

: > David Janes : >

: -snip- : : Excuse me for the dumb question, but I am somewhat confused. : Are you saying that Pro-E will not save updated models in session when : you exit? : That's exactly what I said and Hamei's reply confirmed/affirmed it. Pro/e neither knows, nor cares, nor warns you that you have unsaved data, before it exits. The option prompt_on_exit does just that: it puts that little interruption in the way of exiting that says "Do you really want to exit". There is no automatic file saving, no automatic backup, no automatic anything in Pro/e, except possibly exiting without warning. Have you ever seen a message that says "Some files have changed. Do you wish to exit without saving the data?" and then, if you answer no, puts you into a file save box? I never have. That's a feature of the Windows API. Pro/e avoids any OS-specific operations in order to be able to compile and distribute a single, generic set of code on a single CD that can intall and play on six flavors of Unix plus Windows NT. If you want just a hint of how bizarrely complex the installation and operation of Pro/e is, go to 'Window>Open System Window' and at the prompt, type Set. This will show you a list of environment variables, close to 20 that are just for Pro/e. Then, take a look in the /bin directory and figure out what all the batch files are for. The whole program is a throwback to the 80s when no operating system saved automatically or warned about unsaved data.

: In my example, I do die and mold work. : The model drives the die cavity in the die, and the die cavity drives : the EDM electrode. : There are drawing sheets for all of these components and I often have : 6-8 inter-related parts/assemblies 'in session' including family table : instances of components/assemblies. 'Prompt on exit' SEEMS to save : anything that was changed in session. : : I also have have the following options enabled to help propagate the : model / drawing / assembly changes: : : propagate_change_to_parents yes : retrieve_data_sharing_ref_parts yes : save_objects changed_and_specified : : I would appreciate your comments on the suitability of these options to : keep all of the file dependencies 'up to date'. : : The only other way I know to make sure that the files are up to date is : to only open one at a time in the order of the feature association : part>die>electrode, then close and save all of the parts and open the : associated drawing sheets one at a time. : : Being a prior Solidworks user, I was constantly having problems with : Pro-E until 'prompt on exit', and the other options I selected as listed : above. : There are a plethora of options that seem like they could effect data integrity. I'm thinking of one, create_parameters_from_fmt_tbls, which prompts for the values of any parameters contained in a format whenever you add that format to the drawing. It's a good way to enforce consistency and uniformity of parametric information. However, it's often used to collect information such as names of detailer, modeller, project engineer, checker and possibly design control group. Is it enough that this information is contained in the drawing? should it get back, parametrically, to the assembly/part files so that they form a complete product description? is such information necessary to a complete product description? do you know patent regs and are you a lawyer?

Your question, I'm sure, is more basic ~ you want to know if all the stuff that should be save will get saved. First, I can say that much happens in Pro/e because of its associativity (drawing/assembly/model). Second, the options you mentioned have very precise bahaviours, based on precise situations. Means you ought to go through a disciplined process to find out the effect of changing each and all in various combinations. While those option settings seem appropriate, they may be ineffectual and unnecessary. Take, for example, save_objects changed_and_specified. This is the default behaviour of Pro/e, so the program would behave this way, even if you didn't include this option in a config.pro file. The other option, propagate_changes_to_parents sounds like it means that if you change something in the drawing, it will make its way back into the model. Actually, no, this is done, more or less, automatically. If you change a dimension in a drawing, you should go 'Edit>Regenerate>Model' to get the model to update so that the drawing and model dimensions agree (and, of course, to make sure that changing a model dimension will not blow up an assembly). But, even if you don't regenerate the model, the drawing will save just fine and nothing will be lost. If you print the drawing, you will just notice a highlighted dimension, indicating that the model wasn't regerated with the new value. The option just means that Pro/e will assume that the models have changed (a precaution) if the drawing has changed and save them as well. It may result in some unnecessary saving but no data will be lost this way.

The last option you mentioned, retrieve_data_sharing_ref_parts, setting it to yes may only work with another option, topobus_enable, set to yes. The Associative Topology Bus governs a lot of the exchange of data between different systems, through export files or translators, and helps to keep them current on your end. If you're using native Pro/e models exclusively, this option means nothing. Everything downstream gets regenerated when the models change. If the 'data sharing' reference parts never change, this option also means nothing.

David Janes

I guess I forgot to mention the surest way to make sure data at all levels stays in sync, updated and associate: a PDM system, like intralink or iman. Seems like Pro/e's limitations feed such purchases. Probably just a coincidence.

"David Janes" wrote in message news:YwRoc.52253$Fl5.13673@okepread04... : "Chris Gosnell" wrote in message : news: snipped-for-privacy@corp.supernews.com... : : : : : : David Janes wrote: : : -snip- : : > : There are other options you may want to enable such as 'prompt on exit' : : >

: : > I thought this might be useful, too. But, as Pro/e is not a Windows program : and : : > has neither the intelligence nor the good manners to tell you that you have : : > unsaved data before you close the program, this prompt can lull the naive into : a : : > false sense of security. If you answer it's prompt with a Yes and convince it : that : : > you really and truly and sincerely do want to close the program, it will : happily : : > trash your data for you. This is the Unix way. : : >

: : > David Janes : : >

: : -snip- : : : : Excuse me for the dumb question, but I am somewhat confused. : : Are you saying that Pro-E will not save updated models in session when : : you exit? : : : That's exactly what I said and Hamei's reply confirmed/affirmed it. Pro/e neither : knows, nor cares, nor warns you that you have unsaved data, before it exits. The : option prompt_on_exit does just that: it puts that little interruption in the way : of exiting that says "Do you really want to exit". There is no automatic file : saving, no automatic backup, no automatic anything in Pro/e, except possibly : exiting without warning. Have you ever seen a message that says "Some files have : changed. Do you wish to exit without saving the data?" and then, if you answer no, : puts you into a file save box? I never have. That's a feature of the Windows API. : Pro/e avoids any OS-specific operations in order to be able to compile and : distribute a single, generic set of code on a single CD that can intall and play : on six flavors of Unix plus Windows NT. If you want just a hint of how bizarrely : complex the installation and operation of Pro/e is, go to 'Window>Open System : Window' and at the prompt, type Set. This will show you a list of environment : variables, close to 20 that are just for Pro/e. Then, take a look in the : /bin directory and figure out what all the batch files are for. The : whole program is a throwback to the 80s when no operating system saved : automatically or warned about unsaved data. : : : In my example, I do die and mold work. : : The model drives the die cavity in the die, and the die cavity drives : : the EDM electrode. : : There are drawing sheets for all of these components and I often have : : 6-8 inter-related parts/assemblies 'in session' including family table : : instances of components/assemblies. 'Prompt on exit' SEEMS to save : : anything that was changed in session. : : : : I also have have the following options enabled to help propagate the : : model / drawing / assembly changes: : : : : propagate_change_to_parents yes : : retrieve_data_sharing_ref_parts yes : : save_objects changed_and_specified : : : : I would appreciate your comments on the suitability of these options to : : keep all of the file dependencies 'up to date'. : : : : The only other way I know to make sure that the files are up to date is : : to only open one at a time in the order of the feature association : : part>die>electrode, then close and save all of the parts and open the : : associated drawing sheets one at a time. : : : : Being a prior Solidworks user, I was constantly having problems with : : Pro-E until 'prompt on exit', and the other options I selected as listed : : above. : : : There are a plethora of options that seem like they could effect data integrity. : I'm thinking of one, create_parameters_from_fmt_tbls, which prompts for the values : of any parameters contained in a format whenever you add that format to the : drawing. It's a good way to enforce consistency and uniformity of parametric : information. However, it's often used to collect information such as names of : detailer, modeller, project engineer, checker and possibly design control group. : Is it enough that this information is contained in the drawing? should it get : back, parametrically, to the assembly/part files so that they form a complete : product description? is such information necessary to a complete product : description? do you know patent regs and are you a lawyer? : : Your question, I'm sure, is more basic ~ you want to know if all the stuff that : should be save will get saved. First, I can say that much happens in Pro/e because : of its associativity (drawing/assembly/model). Second, the options you mentioned : have very precise bahaviours, based on precise situations. Means you ought to go : through a disciplined process to find out the effect of changing each and all in : various combinations. While those option settings seem appropriate, they may be : ineffectual and unnecessary. Take, for example, save_objects : changed_and_specified. This is the default behaviour of Pro/e, so the program : would behave this way, even if you didn't include this option in a config.pro : file. The other option, propagate_changes_to_parents sounds like it means that if : you change something in the drawing, it will make its way back into the model. : Actually, no, this is done, more or less, automatically. If you change a dimension : in a drawing, you should go 'Edit>Regenerate>Model' to get the model to update so : that the drawing and model dimensions agree (and, of course, to make sure that : changing a model dimension will not blow up an assembly). But, even if you don't : regenerate the model, the drawing will save just fine and nothing will be lost. If : you print the drawing, you will just notice a highlighted dimension, indicating : that the model wasn't regerated with the new value. The option just means that : Pro/e will assume that the models have changed (a precaution) if the drawing has : changed and save them as well. It may result in some unnecessary saving but no : data will be lost this way. : : The last option you mentioned, retrieve_data_sharing_ref_parts, setting it to yes : may only work with another option, topobus_enable, set to yes. The Associative : Topology Bus governs a lot of the exchange of data between different systems, : through export files or translators, and helps to keep them current on your end. : If you're using native Pro/e models exclusively, this option means nothing. : Everything downstream gets regenerated when the models change. If the 'data : sharing' reference parts never change, this option also means nothing. : : David Janes : :

Chris, your certainty that prompt_on_exit actually made a difference _prompted_ me to look further, to actually check something I was certain of. While checking through config.pro I noticed this other option called allow_confirm_window which I realized, in reading the description, is the option that shows that message "Do you really want to exit?" Then I checked my setting of prompt_on_exit which I'd been certain I had set to 'yes' and turns out I'd never enabled it. I set it to yes and you're correct, it does ask if you want to save changed files. While it doesn't tell you why it's asking, it does preserve the changes. My apologies for introducing confusion instead of clarity.

Another precaution you might want to enable is the similar behaviour with 'Erase not displayed' by setting prompt_on_erase_not_displ to 'yes'.

David Janes

Thanks for the info. I was turning slightly blue after reading your post two levels up... I can breathe now. I have been using pro-e for approx 6 years, and prompt_on_exit was the only thing keeping my sanity.

I do have the topobus_enable set to yes.

I find that one of the most confusing things about pro-e is the need to regenerate manually after changing things. I would have thought that the models/drawings/assemblies would update in a more automatic manner.

For example, if the die cavity references an external 'cutout' model, and the model is an instance in a family table, you must have the particular instance in session for the update to work. If you don't, when you regen the die a message like 'no regen required' will fool you into thinking that the change had taken place. I have forced this to be resolved by setting the option 'retreive_data_sharing_reference_parts' set to yes. This looks at the FIRST ONLY external reference and resolves the models as required. Within the limits of only seeing the first external reference in the model tree, the option seems to be recursive and will chase the update through a collection of models as required (4 is my limit so far).

Lastly, my limited knowledge of the workings of pro-e and interlink seem to be that you checkout the models to be worked on, work on them in a local directory, and then check them back in. Seeing that pro-e doesn't/can't resolve all of the external references, how will Interlink do any better?

Thanks again.

David Janes wrote:

"Chris Gosnell" wrote in message news: snipped-for-privacy@corp.supernews.com... : Thanks for the info. I was turning slightly blue after reading your : post two levels up... I can breathe now. I have been using pro-e for : approx 6 years, and prompt_on_exit was the only thing keeping my sanity. : : I do have the topobus_enable set to yes. : : I find that one of the most confusing things about pro-e is the need to : regenerate manually after changing things. I would have thought that : the models/drawings/assemblies would update in a more automatic manner. : I find, from personal experience and this ng, that the most confusing thing is a plethora of configuration options which are difficult to understand and join with other options to effect Pro/e's bahavior. As to the 'problem' with not regening when changes are made, I'd guess you have blessedly avoided the unexpected, uncerimonious and heartstopping toss into the black hole of 'Resolve Mode'. You are most fortunate to have avoided the thoughtless or accidental modifications which led to this situation. Hopefully, you are also not among those who turned off sketcher 'Intent manager' because it caused your sketches to blow up when it automatically regened each dimension as you modified it. In response, there were the typical workarounds' (Proe being the capital of the universe of Workaround). Some check boxes were later included for 'Regenerate' and 'Lock scale' to counteract the effect of modifying one dimension and having it go 'off the charts'. Well, to be more precise, Pro/e does workarounds to keep from doing the obvious and needed, like giving users the ability to specify the size of their 'working world', i.e., the basic, average size of their parts. This is also one of the chief reasons they tell you to keep your base features and intial sketches simple. How much less troublesome would Pro/e be if it let you specify your 'initial world size'.

: For example, if the die cavity references an external 'cutout' model, : and the model is an instance in a family table, you must have the : particular instance in session for the update to work. If you don't, : when you regen the die a message like 'no regen required' will fool you : into thinking that the change had taken place. I have forced this to be : resolved by setting the option 'retreive_data_sharing_reference_parts' : set to yes. This looks at the FIRST ONLY external reference and : resolves the models as required. Within the limits of only seeing the : first external reference in the model tree, the option seems to be : recursive and will chase the update through a collection of models as : required (4 is my limit so far). : : Lastly, my limited knowledge of the workings of pro-e and interlink seem : to be that you checkout the models to be worked on, work on them in a : local directory, and then check them back in. Seeing that pro-e : doesn't/can't resolve all of the external references, how will Interlink : do any better? : Intralink doesn't try to 'resolve' external references, it just tries to make sure that Pro/e doesn't have to worry about where things are stored in order to find the referenced files, especially where different design control entities are involved. But, since it keeps track of things through a separate database which also tracks designated paramters as well as file locations and relations, it is capable of tracking a lot more than native Pro/e. It makes up for Pro/e's weaknesses in tracking dependencies. It also provides procedures for such things as releasing and can work with such things as Pro/MODELCHECK to insure that standards are met. Many problems which loomed before as insurmountable seem to nearly vanish with a PDM/PLM solution.

David Janes