Does a pending ⎕DL delay abort when a user closes a MsgBox window in Dyalog APL?

Short answer

No. A pending ⎕DL is a blocking, synchronous pause: it does not process GUI events, and nothing the user does with a MsgBox window will shorten or cancel it. The delay always runs for the full specified time, and any dialog queued after it appears only once the delay has elapsed.

What's confirmed vs. likely

Confirmed behavior (well-established): ⎕DL suspends the APL thread for the requested number of milliseconds. Because it is not an event-processing wait (unlike ⎕DQ), the interpreter's GUI event loop is not serviced during the delay. That means:

• If the MsgBox is displayed after the ⎕DL call, the dialog cannot appear until the delay finishes — the wait time before the alert is fixed, regardless of user action.
• If the MsgBox is displayed before the ⎕DL, the user closes it normally, and only then does the delay begin. Closing the dialog does not retroactively affect a delay that hasn't started, nor one that is already pending.

Likely but worth verifying on your platform: the underlying timer implementation differs between the Windows, macOS, and Linux ports of Dyalog. The blocking semantics are the same, but if you depend on precise timing (e.g., sub-100ms accuracy), measure it on each target OS rather than assuming identical behavior.

How to verify in your session

Run this in a Dyalog GUI session and try to interact with the dialog:

      start←3⊃⎕AI ⋄ ⎕DL 5000 ⋄ ⎕MSG 'Test' ⋄ (3⊃⎕AI)-start

You should see the MsgBox appear only after roughly five seconds, and the returned elapsed time should be at least 5000 ms. Then reverse the order:

      ⎕MSG 'Close me' ⋄ start←3⊃⎕AI ⋄ ⎕DL 2000 ⋄ (3⊃⎕AI)-start

Closing the first dialog early or late should not change the ~2000 ms measured delay.

Practical recommendation

Because ⎕DL freezes the event loop, it is a poor tool for pacing UI interactions — the application appears hung while it runs. If you need a timed wait during which the user can still interact with windows, use ⎕DQ on a root object with a timeout, or a timer object firing events, instead of ⎕DL. That gives you deterministic, documented behavior rather than reliance on blocking semantics that a future Dyalog release could refine.

Note: this reflects long-standing behavior through at least Dyalog 18.x; verify on your specific version and OS before shipping timing-sensitive code.