Maximum vs. Selected Records in 6.0

Panorama "Classic"
1

This morning, for the first time, the Maximum function has stopped working. Anybody else ever see this problem? In a procedure, I say

FIELD «F3»
FORMULAFILL ARRAYSIZE(«T3»," ")
MAXIMUM

and a line gets added at the bottom and it’s blank. I can see all the records above it with their numbers in them, and the maximum is not 0. If I stop there and select Maximum from the menu, I get the correct result in the field.

I’ve been using this procedure for some years – never failed here before. Does this remind anybody of anything?

2

Just experimented with a simple version of this in Pan 6 and it worked as expected:

Max

This is in OS X 10.13.4 and Panorama 6.0.0, build 121629.

3

no, no, no
this is an old bug, I only realized later
Make field F3 say 5,4,3,2
then run this procedure:
SELECT F3 = 8
FIELD F3
MAXIMUM
It seems that “MAXIMUM” is one of the many functions that won’t run when a database has been “poisoned” by a selection which returned no records.
In this case, the selection was way back in my code, and was intended to exit the procedure if any records were selected. Panorama always assumes that you only want commands to work on records you’ve selected. This is a wrong assumption. And then it doesn’t put up any kind of error alert telling you it’s decided to go on strike. Sad!

4

This is not a bug or assumption, it is a documented feature. If you want commands that modify multiple records to work on all records, you must use selectall first. For Panorama 6, this is documented on page 556 of the “Formulas & Programming” book. I have included the relevant section below:

Handling Empty Selections

What if the select statement fails to select any records? Eeek! Panorama always requires that at least one record be selected at all times, it never allows every record in a database to be invisible. If none of the records in the database match the formula, Panorama does nothing. It’s as if the select never happened. Whatever records were visible before remain visible after. This can be a problem if the following statements are expect- ing a particular subset of the database to be selected.

Fortunately, Panorama normally handles this situation for you automatically so that your procedures will work correctly. Panorama keeps track of the fact that there should be no records selected, and it will skip any statement that modifies the database, including formulafill, sequence, propagate, unpropagate, etc. (basically any statement that corresponds to an item in the Math menu will be skipped). Panorama will con- tinue skipping these statements until it comes to a selectall statement or another select statement.

Panorama’s automatic statement skipping for empty subsets should work fine for most applications. As a procedure programmer, however, you have the choice of overriding this statement skipping and program- ming your own solution to the empty subset condition.

To test for an empty subset, use the info(“empty”) function. This example calculates the InvoiceAge field only for invoices that have actually been shipped (the ShipDate field is not empty) and that are not paid yet. An error message will appear if there are no outstanding invoices.

select sizeof(ShipDate)≠0 and Balance>0 if info("empty")
    message "No outstanding invoices!"
else
    field InvoiceAge
    formulafill today()-ShipDate
    selectall
endif

Remember, this logic is only necessary if you want to perform some special handling of empty subsets. Nor- mally, Panorama will handle the empty subset just fine on its own by skipping the statements until the selected subset changes.

5

This also is a documented feature

(copyrighted content removed)

Every few years this design flaw comes at me. Long enough for me not to remember that a selection which returned correctly with zero records selected, many instructions back, still has the effect of making Panorama statements not work. (You may guess that I am not a fan of overloading operators.)

Am I really the only one this ever happens to? Maybe I should get a new hobby.

6

You didn’t share what you have in place to exit the procedure, but after writing many thousands of lines of code in Panorama I can tell you very honesty that nothing gets poisoned if you handle selections properly. EVERY selection should be evaluated with info(“Empty”), and then followed by instructions on how to proceed if the selection succeeds or if it fails.

Apparently you want your procedure to stop if F3 contains any records equal to 8. If the selection fails, whatever was previously selected remains selected whether it was a few, many or all records in the database. Sorry, but that seems a bit cavalier or at least too casual in seeking a maximum of whatever those selected records represent. I’d never expect a client to accept that in a process I provide. If there is no 8 in F3, you should tell Panorama what records you do want it to act on to give you a Maximum.

It’s no bug. It’s giving you the responsibility of providing the alternative action if there is no 8 in F3.

a selection which returned correctly with zero records selected

If a selection did actually return zero records, what would you expect from Maximum?

7

No, no, no. I am not submitting my three line test procedure for a code review.

What is actually happening is this.
Make a selection
do things
refine selection
do things
refine selection
and to these last few hundred records, I want to make one last test: I want to see if a field way off yonder has a valid key in it because soon it’s going to be relating to another database.
So my last move is, Select bad references and if the number is greater than 0, tell the user to supply a valid key and don’t go any further.
When everything is correct, the last selection is going to be empty, and it ought to be empty, and then I can proceed to the next steps.

And yes, I do check the result all my selections, and if everybody did that, there would be no need for Panorama to silently override the behavior of an arbitrary subset of its operators, and give mysterious results.

And, n.b., saying “SELECTALL” to restore the functioning of the subset of operators, is not possible in this case.

Of course I can do things differently. I already fixed it.

I’m just telling you: it is not good language design, or UI design, for an interpreter to change the behavior of its built-in operators; and especially without telling you, as it happens. This “feature” was added, to save programmers from the consequences of their not checking the result of their selections. It presumes that the user wants operations to proceed only if the selection yielded positive results; in this case what is being checked is the existence of an error condition, and I want to proceed only if the result is negative.

It’s clear that it’s too late to change it now, but do you see what I’m saying?

Also, did anybody actually get to see the Far Side cartoon I pasted into the last post? It was the whole point of the post. The overenthusiastic censor bot seems to have removed it. It’s the Wings Stay On Wings Fall Off cartoon. And I think you would find that it is entirely fair use, due to being a tiny fraction of the book in which it appeared. The manual excerpt that Mr. Rea quoted is also copyrighted material and the bot didn’t censor that. Hard for me to imagine that Universal Press Syndicate would mind engineers posting Far Side cartoons to each other, and if they did, they need to deal with the Internet.

8

I can’t speak for anyone else, but I already understood what you were doing.

behaviour of an arbitrary subset of it’s operators

It’s not an arbitrary subset, it is EVERY operation that modifies data in multiple records based on the current selection – fill, formulafill, total, etc. Basically everything in the math menu.

Many, probably a majority of Panorama users are not programmers. Many of them couldn’t program an if block if their data depended on it, and it does.

Also, code using these statements can be created automatically with the procedure recorder. I suppose these days some sort of AI could be written to automatically add the necessary test code, but that certainly wasn’t possible back in 1990 when this was originally done.

Suppose someone recorded this code.

select State="WV"
field Debit
fill 0

Now suppose they later run this code but there is no records in West Virginia. Under your plan, Panorama will silently wipe out ALL the data in the Debit field. That is clearly not what was intended, and would result in a VERY unhappy customer.

This behavior is not a bug, it is a feature that was very deliberately put in.

As for fair use questions, if you wish to post Universal Press Syndicate copyright material on your own web server and potentially defend that as fair use, go for it. This forum is here to to assist Panorama users, not to test the bounds of copyright law. As for quoting the Panorama documentation, obviously that is our own copyrighted material and we can use it as we see fit.

I’m going to close this topic, I think it has been fully exhausted.