Naming Conventions

[vsp576]

Can anyone tell me what are the naming conventions used in Crystal Reports

Thank Q

 

[synapsevampire]

Reports are suffixed by .rpt.

Otherwsie there aren't any published standards for objects within Crystal that I've seen.

What else do you need?

-k

 

[vsp576]

I want to find out what naming condition are used for the formulae field ,parameters etc

Thank Q

 

[Madawc]

I think you can use anything you please. I've found it useful to identify formula fields by prefixes, L_logic, C_Calc, D_display. And in running totals, G_value for group totals and T_value for overall, maybe G1_tot and G2_tot if there is more than one group.

Parameters could be P_whatever, but since the various types have their own symbol, @ or # or ?, is it needed?

Madawc Williams
East Anglia
Great Britain

 

[eo]

A referenced formula is identified with a leading @ sign, then your formula description (no rules with the naming of the formula)
A parameter is identified with a leading @ sign, then your parameter description (no rules with the naming of the parameter), etc

 

[Naith]

I think eo means ? for the parameter. Not @.

If you create one of each type of field, and drop them onto your design canvas, you'll see which initial symbol Crystal uses to identify each one.

Naith

 

[Madawc]

@ for formula fields, # for running totals and ? for parameters, at least on my machine. But I use formula fields for many different things, so a prefix is useful. The same applies to running totals at different levels, group or overall.

Madawc Williams
East Anglia
Great Britain

 

[synapsevampire]

table.fieldname = No prefix, just the table and field name
@<name> = Formula
#<name> = Running Total
?<name> = Parameter
%<name> = SQL Expression
Group <X> <name> = Group Name Field
Group <X> <name> <aggregate function> of <field>

All that comes to mind.

-k

 

[Ngolem]

I try to make my formual names reflect their function in the report itself

for example:

Initializing variables : @Initialize_whatever
calculation formulas : @Calc_whatever
flag formulas : @Flag_whatever
display formulas : @Display_whatever
grouping formulas : @Grouping_whatever

I find that by doing this my formulas are organized, less cryptic and easier to maintain when you have to look at them months later

I also extensively use color coding of formulas in design

I conditionally do this by first setting the background color of the field to whatever color (eg: RED) then set the conditional color to a formula like the following:

If 1 = 1 then crNoColor else crRed

This forces no background at runtime but preserves the color in design.

Subreports...Show as background of RED in design...so that you can find them...especially if you make them very tiny. I once spent 3 hours trying to find a 1x1 grid snap subreport on a report that I was given to maintain

I also color code formulas that belong together so I can easily find them in design

Eg. I would color the background green for initialize/calc/display formulas which are related

I also place color coded text boxes in the cornor of sections of a report that are related. Sometimes in a complicated report with dynamic grouping and sections suppressed/unsuppressed it is hard to figure out at a glance what Group header subsection belongs with what Detail subsection or Group footer section....a tiny colored textbox in the subsection that is suppressed at runtime solves this confusion.

So that is the standards I try to use....hope it is useful to you

Jim Broadbent