Formatted text in a field.
james at thehales.id.au
Fri Apr 4 02:30:53 EDT 2014
> So clearly the engine knows how to do these calculations, so I have to believe that all of the properties must be available to us to do the same calculation. The one that I think I am not understanding correctly is the property for the number of pixels in the visible part of the field. I thought that would have been the height of a field - boarder - margin.
If you use the suggested properties you do not need to concern yourself with this sort of calculation.
Take a look at the dictionary.
The formattedheight of a field is the number of pixels required to show all its contents.
The height of a field is the number of pixels you are choosing to view the content.
If the content doesn't fill the field then the height of the field will be greater than the formattedheight.
If you field content is more than can be seen in the field you place on the card, then the formattedheight will be the greater.
The formattedheight takes in to account line breaks etc. in other words it is the height as displayed of formatted text.
The vscroll is the number of pixels from the top of the field CONTENT to the top of the field's window or as the dictionary says, the number of pixels required to scroll down, from the top of its content to where you are.
So for example, setting the vscroll of a field
to the (formattedheight of line 1 to 100) + (the height of field "mytextfield")
Will scroll line 100 of the field's text to the top of the field.
The pageheights property does this and more. It even breaks lines on word breaks. Very clever.
Check out the "engine contributions" forum for the "pageranges" discussion.
It is a user contribution from LC's open source initiative by Jan Schenkel.
Anyway,the gist of all this it that you do not need to worry too much about calculating things. The properties do as the do.
More information about the Use-livecode