Version 23.1 - Problem with private procedures to print purchase orders

We have upgraded to version 23.1 and have run into a problem with private procedures to print purchase orders. Such procedures do not print the totals part of an order. Preparing such a procedure brings up an almost impossible to understand error.

The actual problem is that new parameters have been added to report WWWPORD_3 that prints the totals. All one has to do to correct this annoying error is to add the new parameters as shown below. I've marked the new parameters in yellow.

There is a similar change to report WWWIV_3 that prints totals of invoices; the same new three parameters appear there and so have to be added to all private procedures for printing invoices.

Naming private variables in form triggers

Another problem when trying to upgrade to version 23: an error occurred when trying to add a line to a customer order. As this is an extremely common operation, it was of course very important to solve this problem. The error message said something about variable REF in a certain private trigger; had this variable appeared in the trigger then my life would have been easier.

I was forced to removing all the private triggers from both ORDERS and ORDERITEMS forms: at this stage rebuilding the forms naturally was without problem. I added the triggers back one by one then rebuilt the forms each time until I received the confusing error. I had to do this several times (and of course, remove all the triggers) until I finally found the source of the problem: a trigger included a buffer, and in this buffer I had defined a variable REF. Renaming the variable to TEST_REF solved the problem. Obviously some standard trigger in ORDERITEMS also referenced the REF variable but as a different type.

As always, finding the source of a problem takes a very long time, whereas the fix is normally done in a minute or two.

What can one learn from this? In form triggers, always append the company's four letter prefix to all the variables defined in the trigger, even though these triggers are private. In modern programming terminology, a form and all its triggers constitute one namespace, and so variables must be unique. Employing the company's prefix will ensure that a future predefined variable will not clash with a user-defined variable.

Field names/titles in tables - revisited

My company is trying to update our Priority version from 21.1 to 23.1 and we've had several problems that prevented the update. One problem that can be fixed in advance is that if one adds fields to tables like GENERALLOAD and STACK*, then the title of the field should be the same as the name of the field (or at least, should have the four letter prefix). In other words, if I add a field TEST_INT11 to STACK4,  then the title of this field should also be TEST_INT11.

A previous blog discussed the same problem, but the real cause of the problem wasn't identified there.

Saving a report in HTML format

Until recently, I've never needed to save a report (i.e. create a disk file) in HTML format - or maybe I've always managed to dodge my way around this requirement. Recently, though, I was asked to save a report that I distribute via email in PDF format to save it also as a disk file in HTML. As the report in question is actually an 'HTML document', this is documented as using two extra parameters to the WINHTML program ('-o', presumably meaning 'output' and the output file).

LINK ORDERS TO :$.PAR;
INSERT INTO ORDERS
SELECT * FROM ORDERS ORIG
WHERE ORDNAME = 'KL210001';
:FNAME = '//server/Sharing/AutoReports/$.HTM';
EXECUTE WINHTML '-d', 'TEST_HTMLFURNDAILY', 'ORDERS', :$.PAR,
'-o', :FNAME
;
UNLINK AND REMOVE ORDERS;
LINK ORDERS TO :$.PAR;
INSERT INTO ORDERS
SELECT * FROM ORDERS ORIG
WHERE ORDNAME = 'KL210001';
:FNAME = '//server/Sharing/AutoReports/$.PDF';
EXECUTE WINHTML '-d', 'TEST_HTMLFURNDAILY', 'ORDERS', :$.PAR,
'-pdf', :FNAME;
SELECT ENTMESSAGE ('$', 'P', 20) INTO :SUBJECT FROM DUMMY;
:GROUP = 'FURNDAILY';
LINK GENERALLOAD TO :$.GEN;
INSERT INTO GENERALLOAD (LINE, RECORDTYPE, TEXT, TEXT6)
VALUES (1, '1', :SUBJECT, :GROUP);
INSERT INTO GENERALLOAD (LINE, RECORDTYPE, TEXT)
VALUES (2, '3', :FNAME);
EXECUTE INTERFACE 'TEST_SENDREPORTEMAIL', SQL.TMPFILE, '-L', :$.GEN;
SELECT ATOI (KEY1) INTO :MB
FROM GENERALLOAD
WHERE RECORDTYPE = '1'
AND LOADED = 'Y';
LINK MAILBOX TO :$.MBX;
ERRMSG 1 WHERE :RETVAL <= 0;
INSERT INTO MAILBOX
SELECT * FROM MAILBOX ORIG
WHERE MAILBOX = :MB;
EXECUTE SENDMAIL :$.MBX, :XMSG;  /* send the letter! */
UNLINK MAILBOX;
UNLINK GENERALLOAD;
UNLINK ORDERS;

Today I was asked to do something similar, but in this case, the report is created by a normal multi-step procedure (i.e. not an HTML document), and so there is no use of WINHTML. I looked at the documentation for saving a normal report as HTML - this uses WINACTIV.

The :F variable implies that the report will be saved to a file with this name, but this variable is not used! I looked at the SDK version on the Internet and exactly the same code appears. THIS IS A MISTAKE! The correct code is as follows:

:FNAME = '//server/Sharing/AutoReports/$.HTM';
EXECUTE WINACTIV '-R', 'TEST_HTMLFURNDAILY', 'ORDERS', :$.PAR,
'-o', :FNAME;  

In other words, in the same way that WINHTML receives an extra two parameters when saving a report to disk, WINACTIV does also, only that this is not documented.