Scrolling capture on Windows
Why scrolling screenshots duplicate or skip rows
A scrolling screenshot can repeat or omit rows when its stitcher matches the wrong overlap, the list redraws rows as you move, or content arrives after a segment was captured. Slow down, keep the view stable, and compare adjacent captures using unique row identifiers. If the joins cannot be checked, retain an ordered sequence instead.
- Check unique identifiers
- Wait for loading
- Preserve source segments
How joins work
Similar pixels are not proof of the same row.
A stitcher takes overlapping images, estimates how far the content moved, and discards the repeated strip when joining them. Repeated names, zebra-striped tables and fixed headers can all resemble an overlap.
Virtualised lists draw only part of a large dataset and recycle visual row containers as the viewport moves. Lazy loading adds a second risk: placeholders can be replaced with real content after the capture has already moved on. A larger delay may help loading, but does not make every list stitchable.
A controlled retry
Reduce changes between segments.
- 01
Hold the view steady
Keep window size, zoom, sorting and filters fixed. Avoid hover panels or expanded rows appearing mid-capture. Wait until loading indicators stop.
- 02
Use smaller scroll steps
Keep several recognisable rows in both adjacent images. Move again only after the content is stable. If there is no stable overlap, stop stitching.
- 03
Keep a comparison record
Save the source segments if your tool allows it. Note the first and last unique identifiers in each segment, rather than relying on alternating row colours.
Review
Look for both duplicates and gaps.
- Compare the last rows of one segment with the first rows of the next. An identical identifier should not appear twice unless the source really contains it.
- Check the source order around every join. Consecutive-looking values are not enough when the data allows gaps.
- Compare row totals only when they refer to the same filter and snapshot; a total alone does not identify missing rows.
- Check partially cut rows, repeated headers, delayed images and the final visible record.
Do not repair a disputed record by inventing missing rows or deleting an apparent duplicate without checking the original source. Keep the flawed capture, label its limitation, and recapture or use an authorised data export.
Tool choice
Choose a method that fits the job.
A native table export is often better for complete data; overlapping screenshots are better for documenting the screen layout. Bundlepix is an option for reviewed visual records and identifying partial capture results, not a guarantee that every dynamic list can be stitched.
Further reading
Sources and reference material
Straight answers
Frequently asked questions
Will scrolling more slowly fix every missing row?
No. It can help delayed loading, but repeated patterns, virtualised content and changing data can still make overlap ambiguous.
Is a repeated row always a capture bug?
No. It may be present twice in the source. Compare unique identifiers and the original view before changing the record.
Can a correct total prove that the image is complete?
No. One omitted row and one duplicate can leave the same total. Check identities, order and joins as well.