Determining What Text is in the Current Scrollview of Field

[jacque]

If it helps, I didn't get Craig's joke either until you all started talking about it. Now I think it's clever, but at first it went right past me.

Also, I give up. What does that huge German word mean?

[[-hh]]

..........

[jacque]

Wow. Thank you. Germans must have very good lungs to be able to say a single word like that in one breath.

[dunbarx]

Aha.

We have at last resolved "toUpper(char 1 of abs(-hh)) & char 2 to the number of chars of the value of char 1 of abs(-hh)".

Four or five more japes, and, who knows?

My apologies to the "value" function, but it was the best I could do.

Craig

[[-hh]]

..........

[bn]

Hi,

if anybody is still interested in "what text is in the current Scrollview of field" here is a version that
does not rely on fixed textHeight, it happily accepts different textHeights for each line and even different textSizes within a line.

And you can set "dontWrap" to true and get a part of the field that is scrolled into view with the hScrollbar.

I still don't really see a good usecase for it but it was a nice exercise.

Kind regards
Bernd

@Hermann, with a little external help I managed to count up to 4 (and you might want to check your code, I think "put w into dh" and "put w into dv" should be the other way around, i.e. hScrollbar -> dh, vScrollbar -> dv)

[[-hh]]

..........

[bn]

Hi Hermann,

But the needed time increases proportionally with length (for wrapped text say from 80 to 2000 millisecs as length goes from 10KB to 100KB) because you work with the whole content.
My simple 'click at'-solution from above needs constant time, no matter the length of the fields content.

well, the problem is with non-fixed lineHeight and horizontal scroll on with don't wrap true. As to your suggestions in a prior post. This makes the whole thing slow since you have to get the formattedRect of a lot of chunks.

That said there are a couple of optimizations possible, some of them hinted at in the comments of the code. There are some more I have in mind but

feel free to optimize the code as long as it still meets the following conditions

1. textHeight possibly variable
2. possibly dontWrap true
3. horizontal scrollbar true with possibly parts of the lines/text scrolled out of view

I don't think the click-trick will be enough for that. Actually I was amazed that I got it to work at all

Kind regards
Bernd

[[-hh]]

..........

[[-hh]]

..........

[bn]

Hi Hermann,

that is a beautiful example of a binary search and show the incredible speed-up that is possible when using it. Thank you for this. I will finally have to get my head around binary search and implement it when appropriate.


one minor remark

margins is kind of a tricky beast. If the user changes one of the margins (e.g. topMargin) the margin becomes a 4 item list. So a field that has its margins at the default 8
the margins are "8"
if you change the topMargin to 10
the margins are "8,10,8,8"
Either you ask for left-, top-, right-, or bottom margin individually
or
you test as in your stack

Code: Select all

 put the margins of fld "L" into m
   -- repeat the current items of m, so we have alsways at lest 4 items
   if the number of items of the margins < 2 then
      put (m,m,m,m) into m
   end if

and
when setting the the dontWrap to true and the scoll vScroll is 0 in field "L" then I get

Kind regards
Bernd

[[-hh]]

..........

[bn]

Hi Hermann,

try to set the topMargin of field "L" to 50.

regarding margins:

put (m,m,m,m) into m is correct

-> 8,50,8,0,8,50,8,0,8,50,8,0,8,50,8,0 does work the way you use it, whether it is 'correct' is a matter of debate.

Kind regards
Bernd

[[-hh]]

..........

[bn]

Hi Hermann,

actually it was a 2 part post: on part about handling the margins as variable. That you explained. And I agreed that one can do it that way.

The other part was to actually set the topMargin of the field to say 50 and try to get the visible rect. It has a problem there.

Kind regards
Bernd