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.
_______________________________________________
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
