Drawing format

I am trying to create a standard border for all my wildfire drawings. I
would like to be prompted (on opening said format) to enter various details
about the drawing (drawn by, checked by, material, surface finish, treatment
needed etc.). I can't find anything in Help so wondered if any of you had
any ideas, for which I would be very grateful.
Thanks
Andrea

 

Andrea,

you have to create a format with a table. You can assign parameters to
those tables. If those parameters are defined in the part (assembly)
they will be filled in automatically. If you use templates with
pre-defined paramteres that are designated, then you will be prompted
for those whenever you start a new part with that tmeplate. This should
work for drawings also. Search the help for parameters and templates and
something should come up.

Tom

 

also, if you change your format you will be re-prompted for details. it is
much better to have the parameters in the part or assembly.
if this will require adding paramters to a lot of parts you have previously
created, it is wothwhile creating a hotkey that creates paramters, perhaps
with default vaues. If you are at the beginner stage of cerating formats,
bom's etc, it will be worth learning how to do this, as it is possible that
you will realise in a month or two that you need to add new parameters to
your parts/ assy's.
i don't use wildfire at the moment, so someone else will have to detail that

cheers
Craig

 

: On my formats, I created a table. In each cell of the table I entered
: parameters. If the parameter is in capital letters (&DRAWN_BY), the user is
: prompted for input. If the parameter is in lower case (&scale), there is no
: prompt, and the system parameter is used.
:
Thanks, Scott, for pointing out a couple things, not so far covered:

First, that it doesn't matter how or where you create parameters, and Pro/e has
about a half dozen ways, none of them will show the parameter value in a drawing
or format table without preceding the parameter name with the ampersand sign. This
is just about the whole trick to using parameters in drawings/formats.

Second, that in a case sensitive operating system, like Unix, &scale or &SCALE or
&Scale or &sCale, etc. are all different parameters. And, yes, only the lower case
one is recognized by the operating system as the system parameter. This applies to
the other system parameters, such as &current_sheet, &dwg_name, &todays_date,
etc., as well. While it may be preferable to distinguish user parameters from
system ones by using upper case letters, there is no inherent significance to
parameters with names that are capitalized. They do not automatically request user
input, for example. They may do so, in format tables that contain such user
parameters, *when no value* has been assigned to the parameter, either in part,
assembly or drawing mode. Most Pro/e users who commented already in this thread
favored creating parameters in parts and assemblies. It may seem more convenient
to use the centralized title block or BOM to enter parameter information, but
there are dangers to this method too, the first being that type declaration is by
obscure rules and informal methods when filling in title block/bom parameters,
even if you are highly aware of what's going on. And most users have no idea of
how parameter types are decided when entering tb/bom information. They just know,
for example, that they wanted an integer for a department number and now it,
mysteriously, has a decimal point and trailing zeros or they try to modify the
value and for some reason, they need to enclose the number in quotation marks for
the value to be accepted. An MRP system can be horribly screwed up by this. So I'd
agree with the others: create the parameters in the parts/assemblies, in fact,
load up the start part with them and get people to fill them in when they first
create a part from the default start part. These parameters have a type
deliberately declared, which can always be checked with 'Tools>Parameters'.

That brings me to the last point, namely, Andrea's original question ~ prompted
parameter filling. Dammerl suggested that designating the parameters when they are
created will result in being prompted for values when the template/start part is
used to create a new part. It is necessary, but not sufficient, to designate
parameters. On the page where you fill in the file name, there's a box labelled
'Use default template' which, by default, is checked. You have to uncheck this
box, then select a template name from you start part directory. When the template
is selected, all the designated parameters will display in the area below with an
input line to the right. The input line will be blank, if you set up the
parameters with no value assigned, or it will show the place holder values you
entered. Since parameters are designated primarily to make them searchable in a
PDM system, you may have default, constant parameters that you don't want changed
and don't want to give people ready access to. You should set those parameters'
Access to locked. The parameters will still appear in the start part's input list,
but changing the value will have no effect.

Another way to prompt for parameter values is to use Pro/PROGRAM. When used in
conjunction with the start part (which we will assume already has parameters that
don't require prompting), the start part can be used with the 'Use default
template' box checked, then get parameters for input from Pro/PROGRAM. This is set
up with 'Tools>Program'. Between the two lines that say INPUT/END INPUT, you
should enter a parameter name followed by a type declaration (string, number,
yes/no). On the next line, place inside quotes, some prompt text. Keep going like
this, entering all the parameters and prompts you want to have input. When you
save the program, it will ask you if you want to incorporate into model. Answer
yes and select 'current values'. Save the template file and erase from memory. If
you now use this template in conjunction with the 'Use default template' box
checked, you will have to first select 'Edit>Regenerate' to activate the program,
then select 'Enter' from the menu manager which will start the prompts for values.
With this method, and no values assigned to parameters, you can not just hit enter
to get rid of the irritating request for input. I registers an error and
stubbornly insists on legitimate input.

Some limitations on the method using Pro/PROGRAM:
* 'Tools>Parameters' can not directly remove parameters, this must be done
with Pro/PROGRAM, deleting the lines in the Input section, then the
parameters/values may be deleted from the part with 'Tools>Parameters'.
* Pro/PROGRAM does not recognize the parameter type of 'Integer', only
'Number' which is the real number type. I suppose they figure if you are going to
use the parameter for calculations, a real number will do and if not, then a
string will do.
* A general constraint in parameter management is the fact that their type,
once set, can not be changed, even if no value is assigned to the parameter. You
will get an error if you try to manually change the type in the Input section.
* Most parameter types created through an assignment statement, e.g.,
height=25, will be string, even if quote marks are not used. The only way, in an
assignment, to insure that it is assigned a number type, is to use a decimal, 25.0
instead of 25. This is why, when an integer value is needed, the parameter must be
created using 'Tools>Parameters'.
* Real number parameters pick up the value from num_digits when created. When
it is necessary to limit the number of digits to display, the parameter may be
followed by a decimal value in brackets indicating the number of decimal places,
e.g. [.2], following &total_height, to show the value with two places.

David Janes