I have come across an unexpected failure in an incremented loop. The loop adds a procedure name and the procedure text to two fields in a database. Everything works fine, until a database where the number of procedures was 32.
Below is the pertinent section of code which fails, and shows some of the attempts I made to trouble-shoot the problem. The code before this section correctly enters the procedure names and procedure text for earlier databases. By the way, f1 is the database name of the current database, and the values of nn as 32 and t1 as the procedure name array are correctly shown in the displaydata window.
t1 = dbinfo("procedures", f1) // procedure list array current DB
nn = arraysize(t1,¶)
displaydata nn +¶+ t1
window "Macro List" lastrecord
k = 0
loop // k loop to enter procedure text
k = k + 1
If k = 32
message "STOPPED AT 32"
If k = 33
message "STOPPED AT 33"
«Macro Name» = array(t1,k,¶)
«Macro Text» = getproceduretext(f1, array(t1,k,¶))
until k = nn //end k loop procedures for current DB
When this section of code runs, it stops at the message “STOPPED AT 33”. The message “STOPPED AT 32” never appears. The procedure names and text for the first 31 entries are correct! I first realized there was a problem when PanX objected to a procedure name for k=33. But the last line of this code (until k = nn) means k should never get to 33. The code above was copied and pasted into this thread from the database, so there is no typo involved.
I assure everyone my intention is not to be a gadfly, looking for problems. My wish is to make PanX error-free and faultless. This “Project” I am working on is to convert a Pan6 database, which works without fail, to PanX. The improved features of PanX make this somewhat challenging, but it is a learning project. But how the heck does this loop ever reach k = 33?
If you use a looparray using you t1 list of procedures instead of a manually incremented loop it will avoid this bug, it will be easier to implement, it will work much faster and it is the preferred method in Panorama X. Once you are familiar with the use of looparray you will find yourself using it in many situations.
Thank you so much. I hadn’t expected such a quick response.
I suppose I haven’t been following this forum as diligently as I should. But what a coincidence! That I should have a database with exactly 32 procedures, which is the number which is known to fail. What are the odds?
I will take your advice and use loop array. My old Pan6 habits die hard.
Since this is beta software, looking for problems is a good thing, especially if you can write good bug reports. That means that you want to make it as easy as possible for other people to duplicate your efforts, and verify the problem. A complete procedure that anyone can just paste in and run is the ideal. The closer you can come to the ideal the better. This one was pretty close to ideal, and that’s why Gary and I were able to recognize the problem so quickly.
Bug reports that simply characterize the problem, without describing how to duplicate it, are far from ideal. In many cases reports of this kind will focus on what the user was trying to achieve, without the details of how they tried to achieve it. Someone trying to duplicate it could then be trying a different approach, which doesn’t exhibit the problem. Then we’re left to wonder whether there is actually a bug in Panorama, or whether the bug is in the user’s own code.