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

I've just installed Wildfire on a new machine, and I'm going crazy
just trying to figure out all the new places things have been hidden.
Right now I'm working on getting things to stay the same from shutdown
to startup. How do I get it to remember my working directory? Also,
I don't seem to have any entry for a system color file in my
config.pro. I can save the file, but can't seem to find a way to
reference it, and get it to open each time... Also, when I click on
the don't open browser, it doesn't work. Nothing stays the same from
the time I shutdown to restart... What am I overlooking?

Help?

 

: 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 http://www.3dlogix.com/ and download 'config.pro mentor'
: this will list all of the config.pro and x.dtl options
:
: Lastly go to http://www.proesite.com/ 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 <loadpoint>/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
:
Setting datum_display or any of the other datum feature displays to NO set the
icon to off. But the icon will still be there. If you additionally want to remove
an icon from the tool bar, you need to go to 'Tools>Customize screen'. Control
which toolbars are show and where with the Toolbars page; control which icons are
shown in what tool bars with the Commands page. You can even add mapkeys as icons
this way. To remove an icon, just drag it from the tool bar to the page where it
normally appears. For example, you can find the datum display icons under the
Category outline on the left called View and under that, Datum display. Drag the
icon from the toolbar back to this page, then be sure that you save this where
your config.win normally is read from and the new screen configuration should
'stick'.

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

 

:
:
: 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
<loadpoint>/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:
: : -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
: <loadpoint>/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.
:
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