Priority: writing 'direct activation' reports which are called from a son form

Priority allows one to write reports which are activated directly from a form. In some cases, one doesn't even have to do anything special in order to create such a report, as the following example will show. Let's say that we have written a report which produces data about customer orders; as such, one of the parameters to the report will be the order number. This report can be defined as a direct activation and will work without problem, as Priority 'enters' the order number behind the scenes.

But what happens if one wants to write a direct activation report which is called from a son form?  There is no obvious unique number which can be entered into the report, and some son forms don't have a single primary key, which makes life even more awkward. When writing a procedure which will be activated directly from a form (top level or otherwise), one always has to use the parameter PAR, which will hold one line of the table upon which the form is based. For example, PAR in the context of a customer order will hold a line from table ORDERS, where the value of the primary key ORD will be the value of the order currently displayed.

So, if one wants to write a direct activation report which is activated from the ORDERITEMS screen, one has to write a procedure, in which the first stage gets the primary key from PAR, which is then passed to the connected report. This is done as follows:

LINK ORDERITEMS TO :$.PAR;
ERRMSG 1 WHERE :RETVAL <= 0;  
SELECT ORDI INTO :$.RDI
FROM ORDERITEMS
WHERE ORDI > 0;
UNLINK ORDERITEMS;

Parameter names can only be three characters long, which is why I had to use the unobvious name RDI.

But what happens when the form has multiple fields in its primary key? I faced this problem yesterday when writing a direct activation report based on the DISTRDATELINES (distribution lines per date) form, whose underlying table has a primary key based on three fields. No problem: one simply extracts the three fields from the table linked to PAR and passes all three to the connected report.

LINK DISTRDATELINES TO :$.PAR;
ERRMSG 1 WHERE :RETVAL <= 0;  
SELECT DISTRDATE, DISTRLINE, ROUNDNUM INTO :$.DAT, :$.LN, :$.NUM
FROM DISTRDATELINES
WHERE DISTRDATE > 0
AND DISTRLINE > 0
AND ROUNDNUM > 0;
UNLINK DISTRDATELINES;

It may be that the triple detection for zero is unnecessary; checking for one non-zero value may be sufficient, as there should only be two rows in the linked table (one all zeroes and one with data).

Note that a direct activation report which is defined for a son form cannot be activated as a standard procedure!