Can someone show me how “if error” and “onerror” work? “If error” is actually not in the panorama reference; although it compiles. I’ve tried a lot of permutations, but just starting from scratch:
If I say:
FIELD «T9»
FORMULAFILL DATE(“asdf”)
This generates an error. Where should I place what kind of error statement, in order for my program to do something other than place up the Illegal Date alert?
It doesn’t look like you can trap an error in a FormulaFill.
In general, you put “if error” right after the statement you think might have an error. Whatever code you want to run when there is an error follows if error, and an endif statement follows that.
OnError goes anywhere prior to when the error might occur, and it stays in effect until the main procedure ends. The code you want to run when the error occurs is quoted. It will be compiled and run if and when the error occurs.
If error is discussed on page 258 of Formulas & Programming, and OnError is discussed on page 288 of the same.
As I said, it doesn’t look like either of these work with FormulaFill.
Anybody else think this is worth fixing?
To accomplish what is being done with a fomulafill but allowing for error trapping I would go with a loop instead which would allow you to use onerror or if error. A loop will process one record at a time and thus have the ability to catch each error as it turns up whereas a formulafill operates as a block and cannot trap individual cases. I doubt there is any way error catching could be implemented within a formulafill. Loops are much faster than they were in the old days and if you bracket them between noshow and showpage/endnoshow statements, screen redrawing is totally eliminated until the loop finishes.
I wrote this long post and then only at the end noticed that this post is filed under Panorama Classic, not Panorama X. I think it is still a useful post, so I’ll go ahead and post it anyway.
First of all, if error and all other error trapping is well documented on this page.
In Panorama X error trapping does work with formulafill, though I did find a bug just now (more on that in a moment). If I run this code, I get the message “bad”, just as you would hope.
formulafill date("asdf")
if error
message "bad"
endif
The bug is that the message appears twice!! It doesn’t matter how many records are in the database, the first statement in the error block runs twice. While I’m figuring that out, a temporary fix is to add a nop (no operation) statement as the first statement of the error code.
formulafill date("asdf")
if error
nop
message "bad"
endif
The nop will run twice, but it doesn’t do anything, so no harm no foul.
For those of you scoring at home, here’s the issue I just filed.
So now we know how to trap errors in a formulafill (albeit with a temporary workaround), but you really want to avoid this. As soon as an error occurs, the formulafill stops, so the fill operation isn’t completed. If the error occurs on the 5th record out of 1000, the remaining 995 cells will not be filled.
So I would suggest that you make it impossible for an error to occur. The new Panorama X catcherror( function is fantastic for this. This is one of my favorite functions now, I don’t know how I ever managed without it. Here is a revised
formulafill catcherror(today(),date("asdf"))
Of course you probably don’t want to use today() as the default value in case of an error – maybe zeroblank(0). Since the original post was hypothetical, I don’t know what would be appropriate.
I just thought I would mention that Panorama’s statements don’t have spaces in their names. The statement here is an “If” statement. Error is its parameter. The Panorama Reference actually does document this in the documentation for the “If” statement.
After reading this I just used catcherror( for the first time to make eight procedure lines more tolerant when converting a P6 procedure to PX and it is already one of my favourites, too. Just excellent.
David Duncan
I suppose that LOOP isn’t an impossible option. It took 28 seconds to process 83281 records, vs. 3 seconds with Formulafill. Still, I am doing it 20 times in this subroutine alone.
“The English think 100 miles is a long way, while baby boomers think 100 megabytes is a large file.”
Back in the old days of Panorama the loop statement was almost glacial and the most common choke point in most scripts at the time. I remember using a loop to process and reconvert the individual pixels of a windows icon to a proprietary format used by my commercial plotter at the time. The loop took almost 20 minutes to execute while I went out to do other things. Today using the latest release of Pan 6 this same loop would take only seconds to run. So loops are much faster today than in the early Panorama versions but still much slower than a formulafill or an arrayfilter. Using a loop to navigate through an entire database while in the datasheet will take much longer if you do not encapsulate the entire loop between noshow and showpage/endnoshow statements to prevent constant window redraws.
Rather than using a loop in your situation there might be a possibility you can test for valid dates previous to the formulafill. I have no idea what your exact circumstances are and whether or not this would even be a possibility. Just a thought.
I remember getting my first Mac after several years on the Apple ][ and being amazed that I now had a 40 Meg hard drive. I was certain that I could never use that entire volume no matter how hard I tried.