What are hSscroll, vScroll really?

[Richmond]

On 12/08/2012 06:50 PM, Graham Samuel wrote:
> This is a comment that the LC documentation has not (yet) delivered the goods. I think there's a bit missing (I've tried the user guide, the release notes and the dictionary by searching for the words 'scrolling' and 'scroller').
>
> In the LC dictionary, it says this about hScroll (the horizontal and vertical scrolls are the same in principle so I'll just quote the entry about h):
>
>> The hScroll is the amount in pixels the object has been scrolled to the right. If the hScroll is zero, the object has not been scrolled.
> Er yes, but what is the implied context here? If I create a group (or a field) and plonk it onto the middle of a card, can I make it move to the left or right by changing its hScroll, regardless of any other objects on the card? The answer is 'no' - but the LC docs doesn't explain the underlying context, so one can be left confused by this definition.
>
> What is missing is the idea that a group (or a field) can be narrower (shorter) than the width (height) of its full contents, as recorded in its formattedWidth (Height). Meaningful scrolling can take place when this is the case in one or both dimensions, and it allows us to shift the contents of the object within a frame (which is its rect). It's pretty fundamental, but I just realised that I had never really understood it, which is why I looked in the LC docs for an explanation and couldn't find anything. Having understood it, I find it easier to understand where the implementation of scrolling in the iOS version of LC came from.
>
> If I were really a newbie trying to understand LC, I think I would find this confusing. Does anyone agree that the docs could do with a bit more info about this?
>
> Graham
>
>

The docs could do with a bit more info about lots of things.

However; the docs were written quite sometime ago, and are beginning to 
resemble Mac OS 9;  patches on patches on patches of Mac OS 7.

 From a personal point of view I have found that introducing children to 
RR/LC tends to founder on the documentation.

A lot of the documentation that does make sense to people who have 
already got quite a bit of experience with either RR/LC or
other programming environments does not make sense to newbies as it is 
written presupposing the reader is already familiar with
a lot of the underlying terminology and concepts inwith RR/LC.

There would seem to be a number of possible answers to this:

1. Somebody has to find the time and money to sit down and write a 
comprehensive book that documents all and everything.

2. Somebody has to do the same sort of things as above but have it built 
into the GUI as is the present documentation.

3. There have to a set of incentives to make documenting what a 
developer finds as s/he works with aspects of RR/LC worth
     spending the necessary time away from developing the thing that 
pays for their bread and ch**se.

The problem about number 3 is that that really means that documentation 
comes after the fact rather than before.

The current documentation DOES contain a lot of good, a lot that is 
obscure, and a fair bit missing or incomplete.

Richmond.