After Record Change event oddities: What is causing this?

[fcsw]

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?

[Villeroy]

Regarding Q2, start your routine with

Static n as integer
if n > 0 then exit sub

[fcsw]

@Villeroy: That suppresses the 2nd, 3rd, and 4th passes through the ARC macro. That tells me that a static variable in an event macro persists during the lifetime of the procedure that triggered the event, even though the procedure doesn’t explicitly call the event macro. I didn’t know that and it’s useful information. (I did an additional test to confirm it.)
.
My app is at 1,300 lines of code and climbing. In an app this size, code that suppresses all multiple ARC passes could cause problems elsewhere. The CancelARC function mentioned in the 1st listing gives me more control over what I’m suppressing. There’s little chance of it interfering with other procedures.
.
Aside from that, my code works as it is. ScriptForge.Exception told me where I needed to insert certain lines of code, but it also gave me information about LO’s behavior that I don’t understand. I’m looking for insight into that behavior. But as I said, I did learn something new and I appreciate your response.

[Villeroy]

@fcsw

My app is at 1,300 lines of code and climbing.

This sounds horrible. I use Open/LibreOffice Base since many years with no more than a few dozens lines of code (if any).
IMHO, there should be no need to catch each and every user interaction.
See [Example] Invoice Forms (without macros) (scroll down to “Some Background:”)

[iplaw67]

You should probably report as a bug the smallest functioning unit of code that reproduces the behaviour.

Event firing is somewhat haphasard for some API calls, e.g. where a mutex lock might be required to be acquire or released. Re-entry has also been known to be problematic. It might be that you have triggered such an issue in your code.

You should know that there are relatively few devs that work on fixing these kind of issues.