Priority tip: default parameter values

Procedural (and report) parameters in Priority have an admirable quality: they are maintained from invocation to invocation. Thus if I run a report which requires a date parameter and I enter today's date, that date will appear automatically the next time that I run the report. Most of the time, this is a good idea, but sometimes it is better to have predefined parameters - for example, a report will run on dates from 'the beginning of the previous month' until 'the end of the previous month'.

I am not aware of a method to do this in a standalone report, but it is simple to do this in a procedure: a parameter is defined with a default value in an INPUT step. In a second step (probably SQLI, but also INPUT: there seems to be little difference), the parameter is referenced again, marking its type as 'd' in the 'extensions' subform of the procedure step. This 'd' tells the report engine to use the default value provided and not the last used value.

This technique is fine for date and numbers, but someone recently asked me to prepare a report where the customer number has a default value. Customer numbers of course are stored in the customers table, so defining the parameter would not be the same as defining an unbound date or number. Originally, I had no idea how the request could be successfully answered, but then a few days later, I stumbled on the standard 'delete parts' procedure. This procedure presents an interface similar to the search bar of a web browser: the words 'enter search here' (or similar) are displayed automatically, but these words disappear when one starts typing. In the same manner, the 'delete parts' procedure presents the standard screen for entering a parameter, but displays 'enter part number' in the space for the part number. This is the technique which can be appropriated.

Again, the process has two steps: in the first step, a variable (NOT a parameter) is given a default value, e.g.

:DEFAULT = '11143';

Then in the screen where one defines the parameter for choosing customers, one enters in the 'value' field of the parameter the predefined value :DEFAULT. One also has to enter the 'extensions' subform and mark the parameter with type 'd'. The result of the above is that the customer number '11143' will be displayed automatically although it can be overwritten.

The above is not just an academic exercise: someone else complained that a given report wouldn't work - even though it worked perfectly for me (as usual). This is a clear sign of a problem with one of the parameters being passed to the report: it transpires that I listed a range of suppliers whereas this person left the suppliers field empty. I can now improve this report with the 'default parameter from a table' technique by giving the suppliers field a default value to ensure that the report always works (unless someone perversely deletes that default value from an invocation).