What Dragging the Coverage Handles Actually Changes

The handles at the two ends of a shot track change the start and end positions of the script content covered by that shot. They change the coverage range; they do not change shooting order, scene ownership, or shot number, so a visible change in track length should not be read as a reordering of the record.

Dragging the handles changes only where the shot’s coverage begins and ends in the script; it does not move the take to another scene, renumber the shot, or rearrange shooting order.

What constrains the start and end points

The two endpoints cannot pass through each other: the start cannot move beyond the end, and the end cannot move before the start. They can meet on the same row, which leaves a coverage range one row wide. This keeps the saved result as a directed coverage range. When a handle stops at a boundary, it should be understood first as a range constraint rather than as a shooting-order rule.

Although both handles can change the extent of coverage, they are not two cursors that can cross freely. Changing scene ownership and changing the shot number each have a control in the shot management interface; there is no separate reordering control for shooting order, and this drag does not take that job either. This drag interaction answers only which part of the script the shot covers.

Why the landing point is deterministic

The drag position is tested against the actual position of each script row, with the hit area expanded slightly above and below each row by a fixed distance. Candidate rows are checked in script order and the earliest hit is used, so the same positional input produces the same landing result. The test does not depend on a user-selectable alternate sorting mode.

After a row is hit, endpoint snapping is applied, which means the handle may not finish at the exact screen pixel where the pointer was released. The user can verify the result by checking which script row the handle stops on after the drag. This deterministic rule describes how the landing point is chosen; it does not imply an undo history.

Both handles share the initial row-hit process, but they snap in opposite directions, so start and end should not be interpreted with the same search direction.

Why the two handles snap in different directions

When the start point is adjusted, the rule searches backward for a usable boundary among character rows, action rows, or scene headings; when the end point is adjusted, it searches forward among dialogue rows, action rows, or scene headings. The opposite directions let the start land at the beginning of the dialogue unit it is in and the end land at the end of that unit. The user can verify the snap by looking at the row where the handle finally rests.

This also explains why the two handles near the same passage can stop on different kinds of content rows. The rule is about endpoint direction and usable script content rather than about a media-editing timeline. The accurate term here is “coverage range,” not timeline, progress bar, or editing range.

When the change is actually saved

Intermediate drag positions are used for interface feedback, while the saved change occurs when the user releases the drag. Each moment during the movement is therefore not saved as a separate edit. The final position after release is the result that should be treated as the completed adjustment.

This drag path has no undo action, so the endpoint should be checked before the drag is released. If the range is wrong, it must be adjusted again rather than relying on an undo command to restore the previous drag. That boundary should not be inferred from undo behavior in another editing interface.

Why left and right track placement is a different mechanism

Whether a shot track appears on the left or right is derived from the form of the shot number and is not decided by this drag; How a Shot Number Separates Master from Coverage covers that derivation. When the coverage range changes, the column positions inside both tracks are recomputed, which is a layout derived from the same range data rather than a reordering of records. The article Scene, Shot, and Take Numbers Explained helps separate those identifier layers, but dragging a coverage handle does not rewrite the shot number. Combining track-side placement with coverage-range editing would merge two mechanisms that operate on different data.

Changing scene ownership or the shot number should therefore be done in the shot management interface; there is no reordering control behind a drag either. The drag result answers only where the shot begins and ends over the script content. The user should verify where the two ends of the track sit after release; the coverage range is not exported, so a receiver cannot read it back from any handoff file.

FAQ

Does dragging a handle change shooting order?

No, the drag changes only the script start and end positions covered by the shot. Shooting order, scene ownership, and shot number are not changed by this interaction.

Can the start and end handles cross each other?

They cannot cross. The start cannot move beyond the end, and the end cannot move before the start; the two can meet on one row. The saved result always remains a valid coverage range.

Why can a handle stop on a nearby content row after release?

The landing point is first chosen by row position and then snapped by endpoint direction to a nearby usable boundary: the start looks back for a character row, action row or scene heading, and the end looks forward for a dialogue row, action row or scene heading.

Can an incorrect drag be undone?

This drag path has no undo action. To correct the range, drag the endpoint again and treat the position after release as the saved result.

Axiom One LLC — SlateX. Figures current as of 24 September 2026.