This article applies to:
A slide at the end of a procedure that contains numerous SlideButtons, SlideChoice items and/or SlideSlider tick marks can cause additional .OnsetDelay for the first object on the procedure, on the subsequent procedure run.
NOTE: This does not apply to InLine objects, i.e. this .OnsetDelay still occurs when InLines exist after the last Slide object, and/or before the first object with logging on the procedure.
As the last Slide's end of procedure cleanup activities occur, each SlideButton, SlideChoice item and/or SlideSlider tick mark is re-rendered and removed one-by-one. This process can therefore take a noticeable amount of time when there are numerous Button elements on the active SlideState. This delay can be so large that you may perceive it as a visual delay and/or input lag when you transition from one procedure run to the next.
Each Button element is re-rendered at the end of the procedure only when the Slide is the last (non-InLine) object on the procedure. You can bypass this delay and maintain how your procedure progresses at Runtime by adding a Wait object with 0 ms Duration after the Slide. This provides the procedure with a different last (non-InLine) object.
NOTE: You may still incur large .OnsetDelay values on the first object of the procedure for a variety of other reasons, such as having GeneratePreRun set to TopOfProcedure, see TIMING: Timing of E-Objects . You can determine if the large number of Button elements on your final Slide causes the .OnsetDelay on your first object with "Debug.Print Clock.Read" statements at the start and end of the procedure. You can then compare this value to the overall amount of .OnsetDelay for the object to see if this is where the majority of the delay lies, as well as see this value decrease by a large amount after you add the final 0 ms Wait object.