Determining a scroll based on code unit offsets

[J. Landman Gay]

Hm. My handler fails too on larger offsets but I think it's because there are lines above it 
that have spaceAbove and spaceBelow attributes, and those aren't being taken into consideration 
when multiplying lines by the textheight. I think Mark's example might work if formattedHeight 
adjusted for that.

On 3/27/20 4:15 PM, J. Landman Gay via use-livecode wrote:
> Oops. Not saved. It fails on larger offsets. Maybe I'm doing something wrong. Here's my longer 
> way, it could likely be optimized better. It does rely on a scripted field selection, and the 
> selectedChunk is passed to the handler:
> 
> on grpScroll pSelChunk
>    -- pSelChunk = selected field chunk: char x to y of fld z
>    put the num of words in char 1 to (word 4 of pSelChunk) of fld "tText" into tNumWords
>    put the formattedtext of fld "tText" into tFText
>    put the num of lines in word 1 to tNumWords of tFText into tLineNum
>    put tLineNum * the effective textheight of fld "tText" into tScroll
>    set the vScroll of grp "tTextGrp" to tScroll
> end grpScroll
> 
> Seems like there should be a better way.
> 
> On 3/27/20 2:47 PM, Mark Waddingham via use-livecode wrote:
>> Maybe (the formattedHeight of codeunit 1 to OFFSET of FIELD - the formattedHeight of codeunit 
>> OFFSET of FIELD)?
>>
>> Sent from my iPhone
>>
>>> On 27 Mar 2020, at 17:59, J. Landman Gay via use-livecode <use-livecode at lists.runrev.com> 
>>> wrote:
>>>
>>> In our last episode, our heroine was trapped by the selection of a line containing 
>>> metadata. The heroes of this group saved her. In all cases, scrolling the field was 
>>> accomplished by using the "select" command to bring the line into view.
>>>
>>> Alas, escape from one danger has led to another. The field itself must be inside an 
>>> enclosing group so that it will scroll smoothly on mobile. She needs to translate the data 
>>> from codeunits to a scroll position in order to set the group's scroll rather than the field 
>>> scroll.
>>>
>>> Each line of the data looks something like this:
>>>
>>> 1,103,7
>>>
>>> While 7 is a line number, multiplying that by the textheight doesn't give consistent results 
>>> due to line wrap. The first two items are codeunit offsets but there doesn't seem to be a 
>>> way to translate those into pixel positions.
>>>
>>> Our heroine is once again in distress, though as mentioned here, some of that may be due to 
>>> the inability to reach the keyboard from 6 feet away, which presents its own positioning 
>>> problems.
>>>
>>> -- 
>>> Jacqueline Landman Gay | jacque at hyperactivesw.com
>>> HyperActive Software | http://www.hyperactivesw.com
>>>
>>>
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> 
> 


-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com