…but, after 3 hours debugging and then re-reading the manual, I realise this is a ‘feature’.
But, nevertheless, as it took several hours of debugging to realise this non-obvious problem, I’ll post some code as to where the problem came from, in case it saves others some time in the future.
Run the following code:
[code]“Not A Bug But Annoying” by MattD
Test is a room.
The file of leaf-table is called “bugtest”.
To print leaf offset table:
repeat with N running from 1 to NUM_ENTRIES:
choose row N in Table of Test;
say “[current table row][line break]”;
say “[line break]”;
when play begins:
say “Table before writing file:-[line break][line break]”;
print leaf offset table;
write File of leaf-table from the Table of Test; [!!! THIS IS MESSING UP TABLE AT ROWS 9 TO 12 !!! ]
say “Table after writing file:-[line break][line break]”;
print leaf offset table;
NUM_ENTRIES is always 12.
Table of Test
num ( a number )
30000
40000
50000
1
60000
70001
90000
100000
110000
120000
[/code]
The output will be:
As you can see, the table has been rearranged. At no point did it occur to me that the table would be simultaneously rearranged in memory (not just in the file).
I’ve just spent 3 hours of debugging, and then re-read the manual, specially section 23.13, and then found the sentence: “Any blank rows in the table are automatically moved to the bottom, and only the non-blank rows are written.”, which then explained everything!!! But this is still not clear as to whether it means the table written to file and/or the table in memory.
So I’d thought I’d post this now in case anyone else encounters the same (non-obvious) problem.
Maybe the syntax should give an option as to whether the table order is changed or not, e.g.
write (external file) from (table name), moving blank rows to the end
vs
write (external file) from (table name)
(which leaves the table intact).
This way the workings are clear to the programmer.
Cheers,
MattD