On 26/03/2017 02:25, Mark Wieder via use-livecode wrote:
On 03/25/2017 04:00 PM, Alex Tweedly via use-livecode wrote:
Never done it, but I had a quick play ....
Hmmm... nice approach. And clever use of spacebelow.
If you have a way of determining which line(s) are being changed, then
you could run this only from that line onward to save some time ....
No, I don't think that would work. First of all, you'd need to keep
track of how many lines before the changed line were already wrapped,
so that you could know what line number to start with. So you'd have
to have already predetermined the relationships of the line starts to
the line numbers and either stored that somewhere and keep updating
the list; or work out the line starts each time.
No, not necessary. This all works *entirely* with the "original" (i.e.
unwrapped) lines. It has no knowledge of which lines are wrapped - only
of the height taken by each *original* line in the rendered field (as
given by formattedheight).
So if you make a change wholly within one line, then *all* you need to
do is
- calculate the revised height of the render of this line (say, line N)
- update sHeights[N]
- update spacebelow of line N of field "linenumbersfield"
However, if you add or delete lines (including things like merging two
lines, inserting a CR, etc.) then you need to
- for delete: 'compact' the sHeights array to move all subsequent
entries down
- for insert: move the sHeights array entries 'up', and then calculate
the rendered height for the new line
- and then update the spacebelow for all lines (N..infinity) of the
linenumbers field (i.e. you don't need to recalculate their heights,
just set them)
(And of course the sHeights array should really be a custom prop of the
field so we can generalize it :-)
Secondly, you'll need to trap some events in a frontscript and handle
things like inserting and deleting text, resizing the field/card, etc.
Yeah, well, I did say "If you have a way of determining ...." :-)
But yes, resizing and other events need to be handled - but since we
already have two fields that need to be kept parallel, then any app
using this must be handling resize itself so adding a call to this
function is trivial (and only needs to be done if the width changes, not
the height). It also needs to handle changes to things like margins,
borders (?maybe?), etc. which might be a new requirement.
Not sure why you'd need to do anything in a frontscript - doesn't the
'textchanged' message would cover all cases ?
But in any case - anyone doing a styled text editor, is going to need to
handle all inputs, changes, etc., so they'll have the right
opportunities to do this as needed.
However - it's almost certain that the engine is doing this line-by-line
(i.e. 'paragraph' by 'paragraph') rendering calculation, so it would (at
a guess) not be hard to store that off in the styledText array
structure. Might be a worthwhile enhancement request, if this would be
generally useful.
-- Alex.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
