reporting/currreport-skip-does-not-stop-trigger-code: CurrReport.Skip() does end the current trigger

[Nikolaj1407]

Article: microsoft/knowledge/reporting/currreport-skip-does-not-stop-trigger-code.md (main at 07e324d)

What it says: Skip() does not end the current trigger, so code placed after it can cause side effects for a record that never reaches the output. The good sample adds exit; after CurrReport.Skip();, and the bad sample is flagged for the statement that follows Skip().

Why this looks wrong: CurrReport.Skip() ends the trigger for the current record; no statement after it runs. The Base Application relies on this. Report 111 "Customer - Top 10 List" (W1, BC 28), Customer - OnAfterGetRecord:

IsHandled := false;
OnBeforeCustomerOnAfterGetRecord(..., IsHandled);
if IsHandled then
    CurrReport.Skip();

Window.Update(1, "No.");
CalcFields("Sales (LCY)", "Balance (LCY)");
if ("Sales (LCY)" = 0) and ("Balance (LCY)" = 0) then
    CurrReport.Skip();
TempCustomerAmount.Init();
...
TempCustomerAmount.Insert();
...
TotalSales += "Sales (LCY)";
TotalBalance += "Balance (LCY)";

Neither Skip() is followed by exit. If Skip() did not end the trigger, a subscriber's IsHandled would not suppress the default processing, and customers with no sales and no balance would still be inserted into the top-10 buffer and added to the totals.

The note on Report.Skip() (the record's remaining triggers still run, but the record is left out of the dataset) is about the record's other triggers, not about statements after Skip() in the same trigger. Report.Break() carries the same note, and its page states that Break ends the current trigger.

Suggested fix: say that Skip() ends the current trigger for that record. The bad sample is then not a defect, and the exit; in the good sample is dead code. If the article keeps a concern, it would be the other triggers that still run for a skipped record, backed by a reproduction.