Turning off snap lines via config.pro

Hi all,

Is there a way to turn off snap lines from config.pro?
Maybe a hidden setting?

Thanks

Mike - WF2

 

Blank the layer.
Haven't done it but think I've read you can set layer visibility via config
option. Could also create the layer in template and blank it.

 

Blank the layer.

Oops. Sorry, I do this all the time; get something set up and forget exactly
how it works. I have a def_layer layer_snap_line statement in config pro to
collect them.

 

If that isn't what you meant you could try (although I have no idea

Drawing snap lines. I hadn't considered the snap / draft grid might be what
Mike was referring to.

Something I just discovered: There's some stuff shows on Tools > Environment
when in drawing mode (I had no idea it was "context sensitive"). Snap line
visibility is one of them. I can't find anything about a corresponding config
pro option, though.

 

There are dozens of unconfigurable behaviors in Pro/e. Some, like Snap Lines, have
an "Environment" setting to temporarily turn them off. Most have no way to change
the default behavior and many have no way to change the behavior at all. Default
start parts were a kludgy way of getting around this deficiency, by storing some
of the defaults in the part itself. For example, if you could figure out how to
change the display of hidden lines and could save it in the part, if you figured
out how to change the default modelling "WORLD" size and could save this in your
part or you figured out how to change the default shading color and saved that
etc. But, in truth, dozens of behaviors are uncofigurable, especially through
something like program configuration settings. In fact, you never change the
default behavior of Pro/e: every time you start it up, it starts with the same
default setting; all that happens is that your Pro/e trips over settings
modifications in config.pro, color.map, syscol.scl, ansi.dtl, tree.cfg,
smtdsnsetup.smd, layout001.pro, config.mech and a dozen other chintzy, cheap,
cheesy, obscure little configuration modification files salted all over your
system. None of these chintzy, cheesy little configuration files (including
config.pro) will change the default setting of the dimension cleanup routine to
uncheck "create snaplines" as the default. Boo on cheap, cheesy, half-assed PTC.
They could straighten all this mess out, including giving us a decent default text
editor, making OLE objects look and print correctly and provide a decent
table/spreadsheet-type editor, if only they could spend the money on Pro/e,
instead of buying another company or two, whenever they get a little spare cash
burning a hole in their corporate pockets. America: a land of contrasts (cheap and
cheesy spendthrifts, for example ~ cheap on you, spendthrifts on themselves, in
pursuit of some drunken, deluded fantasy).

Sorry, Mike, the layers suggestion was the best, so far. And that one is, still,
very much start part dependent (i.e. doesn't "turn off" snaplines in
parts/drawings created with a different start part, doesn't create the layers in
parts missing them, doesn't move snap lines automatically to those layers.) Not
quite the general solution you were looking for. Maybe there's some Java
developers out there that know if a java app run through J-link could do the trick
here.

 

... doesn't move snap lines automatically to those layers.

I assume you mean "move existing snap lines automatically ..."?
Defining a def_layer will place newly created snap lines on a layer.
For existing drawings use the Find function (Look for: Snap Line).

I thought it might be possible to use a blank_layer statement in config.pro to
blank the layer when retrieving but I think that might be a wash if ...

http://www.mtov.lth.se/education/mmt160/usascii/proe/configop/blank_la.htm

blank_layer
value

Blanks specified layers when you begin a Pro/ENGINEER session. The
value is the layer ID. This is valid for layer IDs 1 - 32 only. This
is provided for compatibility of pre-Release 9.0 objects. Once the
object is stored in Release 9.0 or later, this option is no longer
necessary.

.... is correct (maybe there was no Save Status prior to 9)?

Anyway I tried "blank_layer snaplines" (my layer name) and it didn't seem to
have any effect. Maybe 'twould work if I used layer ID as it says but I don't
define ID numbers (I've never figured out if there's good reason to do so or
even if "ID" means the number or the name interchangeably).

 

In the layer tree, under Settings, go to the last item, Setup File. If you have
consistently named layers, just do save and it creates a file that saves and will
load your default layer status each time you open a file. Don't know for sure if
it has to be in the same loadpoint as config.pro. But, as I said before, there's a
confusing mishmash of such setup files. BTW, it's just an ASCI file so it invites
manual editing. Classy, huh.

 

... Setup File.

That's interesting, will have to look into it. Is it a read on startup or a way
to save so you can read it in at a later date like alternate model tree configs
(which is all I've use them for)?

Really, though, if controlling visibility via layers is what Mike wants to do
he'll just Save Status.

Well, they can certainly be confusing. I've sorta come to grips with them and
being able to save project related configurations in start up directories, etc.
is something I like. I don't see where being (almost <g>) man readable detracts
anything. One thing I'm sure of: given the choice between Pro/E's configuration
file scheme and a Windoze Registry scheme I prefer Pro/E's hands down.

 

Looks like the latter. After you asked, I started checking it out. You take a file
where you have the status saved the way you want. Then you do 'Settings>Setup
file>Save' and it creates a file called LAY0001.PRO. When you 'Open' this file,
any layer with the same name gets it status switched. If no layer of that name
exists, a new layer is created with the layer name from the setup file. Trouble
is, no properties get saved/created with the layer, so it's all potential: you can
place stuff on it, you can create rules, but that's all manual. The setup file
sets layer status, period, which you can accomplish more effectively by selecting
"Layers" and RMB 'Hide'. Only if you have some complicated setup that you'd like
to be able to apply repeatedly could this be of some use.

Still looks like getting layers and layer status built into a start part is the
best you can do. And when you want to vary from the default, yes, do Save Status.
However, even here, this doesn't help with the Snaplines dilemma. Turns out you
can NOT create a dedicated snaplines property for a layer while you're in part
model. Snaplines is greyed out in the Look for window. You've got to be in drawing
mode to get access to them, which means, no snaplines layer in your start part,
far as I can tell. Maybe in some kind of drawing template (which I've never
figured out how to set up and use.) So, unless you want to create this snaplines
layer in every single drawing you create, even the layers solution is partial and
awkward. Is there a separate way to setup drawing layers?

I disagree, fundamentally. The openness, ease of manipulation, simple technology
of Pro/e's ASCII setup files disguises complete, total obscurity. It's like they
dangle the obvious to make you feel bad that you can't figure it out. Only
recently, for example, has there been a Find for CONFIG.PRO or descriptions
included next to the options (and they are not available in any of the ASCII files
themselves. I suspect it's part of a sales strategy based on first, humilating the
victim [ahem, umm, I meant CUSTOMER or was that CLIENT, hmmm, what's the latest
cant for sucker]. The guys who are experts, who know this stuff cold and can set
up your system to work the way you want make $1000/day. Your company is paying
$1500 to $2000/day for their services. Based solely on medieval, guildish,
monopolistic obscurantism. And this obscurantism is built into these simple,
innocent ASCII text files.

With the registry, I happily admitted being completely outflanked and utterly
defeated. I felt much better. Then, somehow, I felt free to mess around with
regedit, do searches and delete useless stuff left over from defunct programs,
explore, follow the experts' instructions for how to tweak registry settings and
eventually, gain some familiarity. But, I've also found that the programs that use
this functionality for storing settings have fewer qualms, in the program itself,
about telling WHAT you are setting. There's a central place where you do settings,
the input is broken down in some kind of logical fashion, the settings themselves
have a comprehensible description and tangible results. It is, admittedly,
software for the masses. One does not need a computer science degree to set up the
MS Office Suite; true, they offer courses on all those programs, but mostly to
make users more productive, to introduce them to the productivity features. The
basics and beyond are built into the GUI structure of the program, invented, not
by the inventors of such programs as Pro/e [Unix-based, for decades, with that
approach to setup, configuration, and operation] but by the people who went,
seemingly naturally, to GUI, a much different standard (no, in fact, A STANDARD,
not a different one, but an acutal standard, none of which had ever penetrated the
Unix world]. Pro/e is a typical expert system and when the expert Applications
Engineers get done setting your system up, half a million dollars later, the Users
become, officially, the ENEMY. If something goes wrong, hey, it was set up
perfectly, so it must be their fault. So, the chief dictum [addressed to users]
becomes: Don't Change ANYTHING!!!! Don't TOUCH ANYTHING. I've worked in those
corporate environments, suffered under the Sysadmin nazis, and they knew NOTHING
about Pro/e or how it worked. In that world, Unix system administration equaled
Pro/e support. And, if you found someone who was Pro/e proficient, they
bobbedandweaved, phished and fiddlefaddle, talked many philosophical
generalities/verities but, in the end, said the same, anti-user crap: Don't Change
ANYTHING! They enforced users natural tendencies of fear, hesitation and
ignorance. And use-it-the-way-you-get-it. Sorry, Jeff, I've never been like that;
probably why I prefer to be a Windoze user than a Unix administrator [these are on
a par, Unix user is another word for insect]. Unfortunatedly, all your arguments,
all your rationale come from the old, Unix world; heard it many times before, in
that environment, from those people. Didn't like it then, don't agree with it now.

 

Overall; some interesting, possibly valid, if not universally accepted,
perspectives.

Addressing some Snap Line specifics:

Is it possible to create Snap Lines in part or assembly? No, there will be none
to find and there's no use for the layer in part or assembly.

That is correct.

Adding a snap_line def_layer to config.pro will do that transparently.

I guess you could say that. Once you've explicitly or implicitly created Snap
Lines and their visibility annoys; blank the layer, Save Status, done with it
until you want to see them again. Now that I see there's a control in (drawing
mode) Environment I'm not so sure a mapkey to toggle wouldn't be just as nifty
as using layer visibility control. Dunno, I don't have much more interest than
the OP re the subject. Just not a biggie in my book. (My current Biggie is
trying to figure out how one might make up for the lack of Xsec Exclude by Rule.
Now that's a glaring omission in my book. Any tips?)

I don't know. I'm trying, as time goes by, to figure out how I might best
manage drawing setup. I'm drifing away from the use of drawing templates (I
have no use for 'predefined' front, top, etc. drawing views) and putting all the
border entities in a format. Layers aren't carried from format to drawing.
Suppose one might set up a template with predefined layers and visibility status
but what's the point, really? I'm going to, during the course of creating the
views, be doing a lot of layer manipulation anyway.