Windows 10,Version 22H2
LO Version: 24.8.5.2 (X86_64) / LibreOffice Community
Build ID: fddf2685c70b461e7832239a0162a77216259f22
CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Events triggered by adding a new record in a table control.
Below is a listing from the ScriptForge.Exception console.
00:25:48 → 0 Enter Before Record Action macro
00:25:48 → 1 Exit Before Record Action macro
00:25:48 → 3 Enter After Record Change macro ARC Count: 1
00:25:48 → 4 Exit After Record Change macro ARC Count: 1
00:25:48 → 2 Enter After Record Action macro
00:25:49 → 5 After CancelARC, before Reload
00:25:49 → 6 After Reload, before MoveToInsertRow
00:25:49 → 10 Enter After Record Change macro ARC Count: 4
00:25:50 → 11 Exit After Record Change macro ARC Count: 4
00:25:50 → 9 Enter After Record Change macro ARC Count: 3
00:25:50 → 12 Exit After Record Change macro ARC Count: 3
00:25:50 → 8 Enter After Record Change macro ARC Count: 2
00:25:50 → 13 Exit After Record Change macro ARC Count: 2
00:25:50 → 7 After MoveToInsertRow, before new record flag
00:25:50 → 14 After CancelARC
00:25:50 → 15 Exit After Record Action macro
00:25:50 → 16 ARC Count = 4
It’s obvious that Exception is reporting things out of sequence. Because of that, I included a counter integer on the left, with the arrow pointing to it, that gives the actual sequence of execution. On the right is a secondary counter used to identify a given pass through the ARC (After Record Change) macro. If passes 2, 3, and 4 are arranged in order of execution, you get
00:25:50 → 8 Enter After Record Change macro ARC Count: 2
00:25:50 → 9 Enter After Record Change macro ARC Count: 3
00:25:49 → 10 Enter After Record Change macro ARC Count: 4
00:25:50 → 11 Exit After Record Change macro ARC Count: 4
00:25:50 → 12 Exit After Record Change macro ARC Count: 3
00:25:50 → 13 Exit After Record Change macro ARC Count: 2
The code interpreter entered the ARC macro on the 2nd pass, and then made a third entrance, and then a 4th. It then exited on the 4th pass, exited on the 3rd pass, and finally exited on the 2nd pass. (The time shows when Exception received the information. I don’t believe Exception has any way of knowing when a line of code was executed and the information generated.)
My question is simply, why is this happening? Why does the interpretor start a new pass through the macro before completing the previous pass?
A 2nd question is: Why does Form.reload cause the ARC event to fire twice? I know it’s causing the event to fire twice because if I comment out the Reload code, the ARC count drops from 4 to 2, and Exception reports only 2 passes through the ARC macro. Reload moves the row cursor to the 1st row, so 1 ARC event makes sense, but why 2?