Report Customisation Changes in V3

Version Relevance: Upgrading to V3.00 onwards

Issue: What do we need to know about printing and report changes in Caliach Vision version 3?

Jan 12th, 2007

Feedback: Changes in reports in Caliach Vision V3 as a consequence of changes between Omnis Studio V3.3.3 and V4.2 are as follows:

Report Section new properties

$printif: All report sections including positioning sections now have a $printif property. You can enter a variable or calculation in here and then before it prints the calculation will be evaluated. A result of kFalse (or zero) will lead to the section being ignored.

$printheight: If a non-zero value is entered in the $printheight value, the section will maintain a fixed height regardless of wrapping text. (Warning: It is a little odd with wrapping text as it seems to print the last line of text it can based on whether the line's top left corner falls within the $printheight space. So in most cases the last line of scrolled text overlaps the $printheight boundary.) $printheight is not used in any of V3.0000 standard report classes.

Appearance properties: All report sections, unfortunately excluding positioning sections, now have appearance properties under the Appearance tab of the property manager. These can really decorate a report but are not used in Caliach Vision V3.0000 standard reports. They include $backpattern, $forecolor, $backcolor (which decorate the background), $effect, $bordercolor, $linestyle (puts a border round it which extends with wrapped text), $topmargin, $leftmargin, $bottommargin and $rightmargin (these control the margin within the section space that the other appearance properties are drawn; they don't effect the position of any fields or other objects placed in the section.).

Printing section anomaly

We believe this to be a bug, but Omnis won't change this behaviour now. If you move down and up the page using $pagemode and $pagespacing, the lowest point on the page reached will be the starting point for a subsequent section, other than a positioning section. This is significant if, say, you use positioning sections in the header section to place a fold marker on the page. Despite further positioning sections taking the flow back up the page, a subsequent subtotal header or record section will start printing below the marker point rather than where you would expect, leaving a great big gap, typically on page 2 onwards. The only way round this problem is control the positioning section that goes down the page using the $printif property (e.g. $printif=iPageNo=1).

Report field new property

Wrapping multi-line text fields used to be identified as such using text $align property of kExtendingJst. This is now obsolete and has been replaced with a $vertextend property. If this property is kTrue, $horzextend is ignored. If $vertextend is true you can have left, right or centre justified vertically wrapping text depending on the text $align setting (although right and centre are not super-accurate).

Controlling Section Printing in V3

Because of the introduction of the $printif report section property, we have in many cases replaced the use of 'control fields' with $printif calculations. However, you should be aware that the two techniques for controlling sections can produce very different results. A control field is typically a field at the top left of the section with $visible=kFalse, $nolineifempty=kTrue, $nosectionifempty=kTrue. It may be a variable controlled by the program or it can be calculated to zero (not kFalse unless it is a number variable) when the section does not print. Using $printif or a control field have the same effect if the section has no special properties, but not if it has. The reason is that Omnis evaluates the $printif calculation before implementing the section properties, whereas with the control field technique the section properties will always be implemented regardless of whether the control field permits printing of the section contents. So if you use explicit position controls with a section, be aware that if you use $printif, those controls will not apply when the section is controlled off.

Paul Wilson - Caliach Consultant

Feedback: The following are changes in Caliach Vision V3 for documents that use the new address/contacts structure:

Two-address Documents: Control of printing only one address

Traditionally, per V2.1, standard SO, Job and Invoice documents only printed one address if the Invoice and Delivery address were the same. With the new V3 address structure this is more problematic because of the style and element controls introduced. The following offers a number of methods of control that can be applied using the Invoice (INVFILE) as an example.

The data fields that control the addresses are as follows:

INVINVA = Invoice address id number (SOHINVA, JOBINVA)
INVIADC = Invoice contact id number (SOHIADC, JOBIADC)
INVCAD = Dispatch address id number (SOHCADS, JOBCADS)
INVDADC = Dispatch contact id number (SOHDADC, JOBDADC)
INVINAD = Invoice individual address (SOHINAD, JOBINAD)
INVDEAD = Dispatch individual address (SOHDEAD, JOBDEAD)

The program takes these values, fetches the data, applies any element exclusion and formatting rules and leaves THESE prepared values in iINVAddress, iINVTelecoms, iDispatchAdr and iDispatchTelecoms variables that are printed on the document. In a SO they are iSOAddress, iSOTelecoms, iDispatchAdr and iDispatchTelecoms and in a Job they are iJobAddress, iJobTelecoms, iDispatchAdr and iDispatchTelecoms.

Method 1. Any difference at all: The following will print the dispatch address if it differs in any way from the invoice address, even the use of bold, italic, etc.:

iINVAddress<>iDispatchAdr

Method 2. Textual differences: The following will ignore any formatting differences and compare the text. This will print the second address even when the addresses and contact are the same but when the style includes different elements.

$ctask.tPrint.$StripFormatting(iINVAddress)
    <>$ctask.tPrint.$StripFormatting(iDispatchAdr)

Method 3. Different addresses or contacts: This will cause the second address to print only when there is a different address record, contact or individual address but will ignore any style or inclusion controls.

INVINVA<>INVCAD|(INVIADC<>INVDADC)|(INVINAD<>INVDEAD)

Method 4. Different addresses only: This is similar to Method 3 but ignores differences in contact record.

INVINVA<>INVCAD|(INVINAD<>INVDEAD)

Getting Access To Address/Contact Individual Data Fields

In all multi-address documents the Address (ADRFILE) and Contact (ADCFILE) fields are indeterminate unless you explicitly call for them. You can do this using the $autofind technique. For example, to make the invoice address fields available create a field with the properties: $dataname = ADRFILE.ADRID, $calculated = kTrue, $text = INVINVA, $visible = kFalse, $autofind = kTrue. Then to the right and below you can place ADRFILE fields. In this case, if there is an individual invoice address, INVINVA will equal 0 and so all data fields will be blank.

For more details on the address and contact system in V3 see ?.

Paul Wilson - Caliach Consultant

Other relevant issues in the Knowledge Base: