That is still happening irregularly but I can’t reproduce it reliably. Meanwhile, here’s a variation - in the same database that exhibited the original problem:
In the database, I record daily, both sitting and standing, my systolic and diastolic blood pressures and my heart rate. Entering the final value for the day triggers this procedure which tidies up, saves and closes:
As you can see, it sets up an endless loop which I can exit only by forcing a quit, even though there’s a stop statement in the procedure. There are no other triggered procedures in the database. This behaviour is totally reproducible.
I don’t expect that anybody will have an explanation for this but Jim may be interested in looking at it. There again, he has more important issues to deal with.
Is this procedure being called within a loop with try and catch statements? If so, it’s consistent with an error occurring, after the message statement, and before the stop statement. The error would prevent the stop from occurring. The catch would handle the error, and unless the code for handling the error stopped it, the loop would continue.
It just occurred to me that this is not consistent with multiple messages appearing on the screen at the same time. So maybe try is treating the pause in the procedure while it waits for you to dismiss the dialog as an error interrupt, and it’s “handling” that. That would be a bug.
How is this a variation? There is no Try/Catch in this code.
How is this procedure triggered? Probably in the Code option for a field, or from a form. In either case, code that is automatically triggered this way should not switch windows, Panorama doesn’t like that at all. In this case the message statement counts as switching windows, which I think is confusing Panorama and causing it to start the procedure again. I’ll bet if you remove the message statement the procedure will work fine. If you must have some indication of what is occurring I suggest using the nsnotify or console statements, neither of which pop-up a window.
You are correct, as are your introductory assumptions. I inserted the message statement in an attempt to track what was happening because, without it, the code is run twice - each of the addrecord and downrecord statements is executed.
Hi Michael, in case you have tried this approach, someone taught me recently about using console statements instead of alerts for troubleshooting signposts in code. With the console.app open, the console statement sends whatever message you include. In Console, you can search for PanoramaX to filter and show only the messages you want. Otherwise, it’s like drinking from a firehose. Also let’s your code fail much faster! No user intervention needed.
In the future, probably best to start a new thread when switching to a new topic.
Do you have both the data sheet and a view-as-list form open at the same time? That will cause problems with downrecord and uprecord that sound like what you might be describing.
When the first message came up, I clicked on OK and that triggered another message. Each subsequent click on an OK button triggered a new message. It would have gone on forever which is why I had to force quit.
Removing the message statement gets rid of the endless messages but, if the active record is the last visible record, the procedure executes the addrecord statement twice and then enters the data values.
I’ll create a new database and see if I get the same result. I’m betting that I won’t.
The interaction between the message statement and other statements will presumably be well documented when the Alerts page is written. In the interim, some simple warnings would be useful. Similarly, the effect of having the procedure window open warrants some explanation.
I agree and I always endeavour to do this but, in this case, I saw the two procedures as very similar in that each of them causes a procedure to repeat a section of code for no apparent reason. If there really is a bug, the two of them might have assisted in its identification.
I didn’t say anything about the procedure window. I asked if you had the data sheet and a view-as-list window open. Looking at your larger screen shot, I don’t see any view-as-list form, so perhaps I was wrong about that. It looks like maybe the only data window you have open is the data sheet, so I think I am barking up the wrong tree with that idea.
Does this database have a .CurrentRecord procedure? That would get triggered when AddRecord or DownRecord is executed. Depending on what is in the .CurrentRecord procedure, you could have inadvertently coded in an endless loop.
Your original post said “Entering the final value for the day triggers this procedure which tidies up, saves and closes:”. Triggers how? Can’t be from a menu since the procedure name starts with a period. So I assume it is triggered by data entry. How does it know that it is the final value for the day? It looks to me like you are getting extra triggers that is causing this procedure to run over and over again. For example this could happen if the .CurrentRecord procedure is calling .CheckEntry, or if you have a .NewRecord procedure that is calling .CheckEntry. You need to go thru your database with a fine tooth comb and find every possible way that .CheckEntry could be triggered.
If you look at the screenshot of the data sheet, you will see that a date field and six numeric fields are filled. The sixth numeric field (the last for the day) triggers the procedure which appears in that same screenshot. No other procedures are triggered.
Using my fine tooth comb, I can confirm that the .CheckEntry procedure is triggered only by the data sheet entry.
A further peculiarity is that if that procedure is triggered from a record other than the last visible record, Panorama X crashes, as in quits completely. this may imply a corrupted database.
Michael, your screenshot shows funny things in the Date field that do not fit to what you intended with your code.
Your code adds 1 to the last date; but your screenshot is showing three records with the date “1 Jan”. That only happens when the record above has an empty Date field. This is the case for two of them — I think at one point there was an empty record before the first January date, too, wasn’t it? The year of this January date might be different from what you expect. In my test it is the year 0.
So I think you might possibly be editing the last field in your last record and accidentally — e.g. by hitting return twice — create a new record (with an empty date) before your code adds another record.
Another thought: You say this is a daily routine of yours; so you can omit the date calculation in your code by setting the default value for the Date field to “today”.
That’s just the result of testing the procedure when the date field was empty. The empty records followed by 1 Jan dates illustrates the way in which the procedure executes twice.
