Hi Neil, > A possible implementation of range sizing would be to perform a > synchronous lexing and layout of the whole file (or initial fixed size > portion) to discover the maximum pixel width. Another is to maintain a > maximum seen pixel width in the line layout data and modify the scroll > range when this changes at the end of painting or in periodic or idle > processing. Approximate widths could be discovered by counting line > widths in bytes and multiplying by an approximate per-byte byte width > (making allowance for such things as tabs and multi-byte characters).
In PN2 I have a thread that runs in the background after a document is loaded that scans through measuring each line. I maintain a "longest line seen" value and base the scrollbar size on this. Of course this has to be capped on Windows (to 1000000 on NT and 30000 on 9x) because of the drawing and scroll size limits. This works ok, and the rest of the time the scrollbar is updated as the user types. It obviously doesn't cope well with the case where the user pastes long data in and other similar cases. I'm not suggesting that a thread be used in Scintilla - we're all aware that would be a platform nightmare. Something in the control would work much better for this as the length calculation could be performed as part of the drawing (as you suggest). The main thing is that I think it's more important that we allow the user to see all the data (and thus expand the scroll-width) than that we shrink again afterwards - this is useful but not essential. Simon. _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
