Scrolling list field handling

[glenn9]

Hi,

Is it possible to ‘handle’ scrolling to the end (or beginning) of a scrolling list field?

What I want to achieve is that when scrolling to the end I can then switch to another scrolling list field, eg from list A to list B?

Many thanks

[dunbarx]

Hi.

If I understand you, on a new card, make a scrolling field with lots of lines in it. Explicitly set the textHeight of that field to, say, 12. Make another field. Put this into the script of the scrolling field:

Code: Select all

on scrollbarDrag
   put the scroll of me &&  the textHeight of me * the number of lines of me - the textHeight of me + the height of me into fld 2
   if the scroll of me >  the textHeight of me * the number of lines of me - the textHeight of me + the height of me then answer "Do something"
   if the scroll of me = 0 then answer "Do something else"
end scrollbarDrag

The first line will just show you what is going on while you scroll, the other lines can be modified to trigger other handlers.

Craig

[glenn9]

Hi Craig,

Many thanks for looking at this and apologies for the late reply.

The code triggers perfectly when the scroll of me is 0, ie at the beginning of the list, but it triggers prematurely at the other end, ie well before reaching the end of the scrolling list.

I'm think I'm also not understanding some basic concepts!

My understanding so far:

Code: Select all

textHeight of me * the number of lines of me 

I guess gives the 'total' height of the scrolling list field?

and

Code: Select all

the scroll of me

tells me my current scrolling list field 'position'.

However, I don't think I understand what

Code: Select all

textHeight of me + the height me

gives me or relates to and why its important in the calculation?

Grateful for any additional help!

Kind regards,

Glenn

[dunbarx]

Its always something.

It seems that it is easy to know when you are at the top of a scrolling field, in that the scroll property will be "0".

But right now I do not see a direct way to know when you are at the bottom, hence all that stuff.

Here is a kluge:

Code: Select all

on scrollbarDrag
   put the scroll of me & return &  the textHeight of me * the number of lines of me + the height of me into fld 2
   if the scroll of me = 0 then  put  "Top" into fld 3 
end scrollbarDrag

on mouseMove x,y
   if y  > (the bottom of me - the textHeight of me) then put  "Bottom" into fld 3 
end mouseMove

The problem is that there are no properties I can find about the thumb in a scrolling field, whereas there is indeed information about the thumb for a true scrollbar. And since there is no "maxScroll" property, we have to go through these machinations. But I bet there is a simpler way. I just have to find it.

Craig

[bn]

Maybe

Code: Select all

on scrollbarDrag pValue
   local tMaxScroll
   
   put the formattedHeight of me - the height of me into tMaxScroll
  
   if pValue >= tMaxScroll then
      ## get the action out of handler scrollbarDrag by sending in time
      ## otherwise nasty things can happen, e.g. crash
      send "doAnswer" to me in 0 milliseconds
   end if
end scrollbarDrag

on doAnswer
   answer  "You reached the end"
end doAnswer

Kind regards
Bernd

[dunbarx]

Bernd.

Nice.

The formattedHeight takes card of all of that extra stuff.

Craig

[glenn9]

Bernd, Craig,

Many thanks, this works perfectly and I understand all of the code except why

Code: Select all

formattedHeight of me - the height of me

is needed (apart from the fact it doesn't work without it!) ie I'm not understanding why I need the difference between the formatted (the full content height) and height (I'm assuming the 'visible' height?) of me.

My brain is saying to me I need to reference where my scroll position is in relation to the 'full content height' but its struggling with why I need to reference the difference between the formattedheight and height of me!

Grateful for any tips!

Regards,

Glenn

[bn]

Hi Glenn,

when you set the scroll to 0, i.e. the top of the content is showing and then you scroll down to see what was the bottom part to show at the top of the field. The scroll is then the height of the field. That is why you have to subtract the height of the field from the formattedHeight of the field.
Try it out with a field that reports the vScroll and then scroll.

Mind you there is a vScroll and a hScroll, if you do not specify the v/h then it is understood that you want the vScroll.

Kind regards
Bernd

[glenn9]

Hi Bernd,

have just tried looking at the vscoll but still not getting it yet!!

I think I'll need to ponder on this a bit more but thank you and Craig for trying to help.

Kind regards,

Glenn

[SparkOut]

Lets see if we can make it clearer.

The field size is the fixed "viewport".

The field content will not fit entirely within that viewport, so there will need to be a vScroll.

The formattedHeight of the field is the height that the field would need to be to allow all the content to be viewed without needing to be scrolled.

With a vScroll of 0 the top of the field contents is the at the top of the field.

There is some of the field contents visible, down to the bottom of the field's height. This can be viewed without scrolling.

If you were to set the vScroll to the entire formattedHeight, then the *bottom* of the content would be scrolled to at the top of the field, leaving a blank area of field "viewport".

So, the maximum amount you want to scroll up is to show the bottom of the content at the bottom of the field. Hence take away the height of the viewable area from the actual formattedHeight, so that you only scroll the content by as much as it takes to lift the bottom to be visible at the bottom.

Does that make it easier to see?

[dunbarx]

What Sparkout said.

There are a lot of "formatted" things. They all bear practicing with, since they "contain" certain properties that are only partially represented by whatever you might have as the visual expression of a control on screen. The hidden lines in a long field are a perfect example. The height is the actual physical height of the control. The formattedHeight is just what Sparkout said, the height of the control if ALL the lines were actually visible. You might need a very tall monitor to see that sort of thing.

If there were no hidden lines, the height and the formatted height are identical.

In the scrolling list discussion, this property cuts through all the machinations of calculating the number of lines, the textHeight, etc.

Craig

[glenn9]

Many thanks to all, I think I now get it!

It's the 'not visible' section of the scrolling list field that is the reason why I need to scroll, ie I need to scroll to make it 'visible', and therefore to determine the height of this 'invisible' section I need to subtract the 'visible' height (height of me) from the total height (formattedHeight) which gives me the amount I need to scroll, ie the tMaxScroll (from Bernd's example).

As is so often the case, I can't think why I didn't realise this in the first place!

Thank you again for all your help.

Kind regards,

Glenn