Good stuff, Jeff. Thanks for posting that.
In the olden days I had to be very careful about attempting to update
things on scrollBarDrag because the performance hit was often quite
noticeable, but on modern systems I must say I've been impressed with
the combination of general system performance and the smart way the
scrollBarDrag message is sent to support that sort of thing.
Not long ago I needed to draw a series of polygons with certain shapes
and locations relative to positions of chunks of text in a scrolling
field. After some experimentation I was delighted to find out well it
worked to do that dynamically on the fly, calculating and rendering the
polygons in response to scrollBarDrag.
But on that project I had one advantage I don't have with a script
editor: the field I'm doing my calculations with is read-only, whereas
a script editor's contents are dynamic.
I also had no choice: in Rev, objects are limited to 32,767 px in
height, but of course for a field with a lot of content I could (and
did) easily wind up needing a polygon much taller than that. This is
similar to the problem Trevor's DataGrid solves, in which contents that
would be prohibitively tall can be rendered dynamically if needed.
But since line numbers can be done in advance without difficulty it
would not have occurred to me to render them dynamically.
How responsive do you find that algo with carriage returns?
If a script editor provides auto-indenting the returnInField message is
already pretty well loaded with code, which is why I've been reluctant
to add more to it with things like dynamic line numbers. Memory size is
usually minimal with prefab line numbers since they generally take up a
small fraction of the space of the script itself, and I would be
reluctant to also page the script in an out of the field in response to
scrollbarDrag for the complexity it adds and given that the engine's
field buffering is some of the best in the biz.
But if your experience is favorable it may well be worth exploring that
in my next revision.
Thanks again for the provocative take on this problem. One of the great
things about Rev is the wide variety of ways a given problem can be solved.
--
Richard Gaskin
Fourth World
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
Jeff Massung wrote:
I gotta say, my name is Jeff Massung, and I disapprove of that solution. ;-)
I love everyone sharing their ideas, but this is one that's been a solved
problem, well... for a very long time, and with a little math there's no
performance issue what-so-ever, and there's no need to keep around a field
with thousands of numbers in it.
Think of what we know:
* The size of our editor.
* Where the scrollbar is.
* The size of the font we're using.
From this, there's very little we actually need to do. Even with the largest
monitor on the planet and using the smallest (readable) font, the number of
average lines visible to any user is well < 100. So, generally speaking, we
should never need to do much more than count to 100 at any given point in
time to update our "gutter" area containing line numbers.
So, here's a little script taking from my editor. It assumes that the the
gutter area is always sized to the same height as the editor, that the line
height is fixed (read: we're not embedding images or changing the font
size), and that the editor has line wrapping turned off. With a few tweaks
it could work just fine with those features on, but for the sake of this
discussion, we'll leave them off.
on updateGutter
local tHeight
local tTextHeight
local tScroll
local tFirstRow
local tRows
-- wipe the gutter clean
put empty into fld "Line Numbers"
-- snag what we care about from the editor
put the vScroll of fld "Editor" into tScroll
put the effective textHeight of fld "Editor" into tTextHeight
put the height of fld "Editor" into tHeight
-- calculate the first visible line and the total number of visible lines
put tScroll div tTextHeight into tFirstRow
put tHeight div tTextHeight into tRows
-- fill in the gutter with the line numbers
repeat with tLine = tFirstRow to tFirstRow + tRows
put tLine + 1 & cr after fld "Line Numbers"
end repeat
-- scroll the gutter (every so slightly) to match the editor
set the textSize of fld "Line Numbers" to the textSize of fld "Editor"
set the textFont of fld "Line Numbers" to the textFont of fld "Editor"
set the vScroll of fld "Line Numbers" to tScroll mod tTextHeight
end updateGutter
That's pretty much it. Now we need to know when to update the gutter area.
We need to update it when:
* on scrollbarDrag (the editor)
* when the we reset the editor to display something new
* when we resize the editor (and subsequently the gutter)
HTH,
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
