load model tree prefs by default?

this is about 2001 (or lower versions):

is there a way to load the model tree prefs,
other than from the pull-down menu?

It would be nice to have the desired options
loaded automatically since doing this manually
- again and again and again - is annoying.

Any idea?

TIA & Cheers

Walther

 

Use a mapkey:
Set your model tree up the way you want it
save that tree.cfg into a file
create a mapkey that calls it back from that same place.

I named my mapkey `t

That loads my tree config with all the parameters shown that our
company uses.
I had that setup in 2001 and do the same in WF2.
(I had to re-make the mapkey in WF2)

Hope this helps!
Krullmi

 

I dont have a 2001 install handy, but Im almost positve that the
config.pro option mdl_tree_cfg_file pointing to your tree file will do
the trick.
in model tree, save the setting to a file , and then set the above
option to point to it including the path. also make the config.pro
available in any of the standard load on launch locations.

 

[ what I´d call a workaround - eases the pain, not completely, though. ]

yes! Great idea... if only it worked for me (it did not, yet).

I use a centralized config.whatever directory located on a server,
read only to all users, each of whom I grant a link to the original.

Still, the Model tree prefs have to be read in manually (sigh),
so the question of my OP was, maybe, a little too imprecise.

So again: How do I enforce proe to read in its tree.cfg by default?

TIA

Walther

 

Have you tried to create a local config.pro in the local start-up
directory, with that option pointing to a tree.cfg file with a path
that has no spaces in it;
The option does work, and it is vaild in 2001 .
Im making the assumption your using Windoze.
It may be that that option doesnt like network paths/files and /or
spaces in the filenames.

( Yes Dave J. Im thinking of PTC's/MS's horrid path with spaces
issues)

 

and corrected here I stand... it works fine.
Sorry, I just managed to put a typo into the path 8-(

<off-topic>
No, fortunately I´m still on SGI´s IRIX ...and using XVM.

So I´ll never run out of drive letters - or disk space ,
since I can expand logical drives through adding physical ones,
increase speed by having some disks accessed in parallel,
or data integrity / safety through live mirroring etc.
</off-topic>

Network paths/files are not at all a problem, of course.

Actually, I keep the directory for the proe config thingie
on a server different from the one providing the user data.
That eases maintenance a lot - users may override locally,
but only on a per-session base.

Thanks to you all for your help!

Walther

 

Yes, thanks! i didn't know about the config setting to start proe with
a tree config file.

Just a final note on the mapkey calling the tree.cfg:
In assembly mode i tend to need the parameters showing in the model
tree, in part mode I'm usually interested in seeing the feature number
and feature id only.
I actually have 3 mapkeys to call tree configs. One shows all the
parameters (when I'm in an assy) and the other shows just the feature
number and feature id (when I'm in a part).
The third shows shows the parametes, no features and no annotations.
That is more desireable when I just want to see the components in an
assy without the visual noise of the features and notes....more like
looking at an indented BOM.

The mapkeys reduce the milage on my mouse when flipping between the 3
set ups.

Krullmi

 

nice process with the mapkeys

 

Yes, mapkeys are quite useful... but there is a certain disadvantage:

Every time PTC chooses to stir up the GUI again, i. e. rename
or reorder the whereabouts of functions, mapkeys become obsolete.

Since most of the "development" on Pro/E takes place in the GUI
- c´mon, David: go add a little of your fine rant here ;-) -
this sadly happended pretty often in the past.

We had a whole _library_ of mapkeys for several purposes here,
which an intern has worked on intensively/lengthy in V2000i²...
not useable any more in 2001. Sigh.

Would have been a good idea to totally separate the GUI from the
underlying functionality - make it user defineable - or at least
provide some sort of mapkey converter.

But since the early days of V13 it has always been a strange thing
what PTC regards upon as beeing a good idea.

<Another one: incompatible data formats from version to version,
and no way to convert backwards (blackmail customers into upgrades)>

I have not jumped onto the wildfire train yet and am happy with it.

Walther