Looping with AddRecord works exactly 31 times, then goes nuts

Panorama X
1

I have a simple procedure that first uses fllecatalog() to create a text array of file and folder paths, and then loops to add a record to hold the path stored in each array element. If there are 31 or fewer items in the text array, the loop works as expected. If there are more than 31 items, it works properly for those 31 items, at which point it seems to switch to an infinite loop of adding records and leaving them empty. Is anyone aware of a rational explanation for this? Here is the procedure:

local thefolder,lof,numfiles,ctr
choosefileDialog thefolder,"folders",true()
lof=filecatalog(thefolder,"includefolders","true")
clipboard()=lof //I used this to confirm that filecatalog correctly captures all files and folders in lof
numfiles=arraysize(lof,¶)
ctr=1
Loop
    AddRecord
   Path=array(lof,ctr,¶) //Path is the destination field; changing the field name has no effect
    ctr=ctr+1
Until ctr>numfiles
2

I can confirm that the code you are using does go bananas after 31 or so items. My experiment using this code entered over 8000 records before it timed out and stopped. If I change the code to use a looparray it does not have a problem with any number of items and stops as expected when they are all added. My sample folder contained 157 paths and added them all correctly and then stopped.

Here is the code I used:

local thefolder,lof,numfiles,ctr
choosefileDialog thefolder,"folders",true()
if thefolder="" stop endif
lof=filecatalog(thefolder,"includefolders","true")
Looparray lof,cr(),element,item
   AddRecord
   Path=element
endloop
3

Some additional info on the original loop anomaly as reported in my Console. Here is an image with a partial list of errors returned when the loop went crazy:

image

4

Hmm, I avoided looparray because according to the help file it doesn’t work with recursion, but I guess the recursion takes place in the filecatalog() function and so isn’t relevant to looparray. Thanks for the tip.

Incidentally, using show/hide in the original procedure removes any sort of limiter on the code. I first ran it with show and hide, left, came back in an hour or so to see it had created >150 million records and was still going strong!

5

Although they are now the same in their actions, you should be using noshow & endnoshow in new code and avoid using hide & show. The Panorama X Preferences under Advanced has a setting for limiting the time a procedure can run before it is timed out. I doubt that using noshow would disable that feature. Mine is set to 60 seconds so that is why it stopped with about 8000 records added.

6

Oops, looparray worked fine for a while, then I hit a folder that did the same “31 records then cablooey” thing. I suspect it’s a function of the number of records involved; this folder has just over 16,000 records, and a folder inside this one with just over 10K records also triggered the reaction.