One approach you can take is to remove all the TextLines and run the generic TextLine rendering algorithm again. The best approach is to use the TextBlock’s firstInvalidTextLine value. The theory is this: whenever you modify the TextElement.text property (or any property that affects the rendered text, such as the ElementFormat, FontDescription, etc.), the TextBlock marks the lines which render the affected ContentElements as invalid. For performance’s sake, you should only re-render the TextLines marked invalid (you can read the status from the TextLine.validity flag).

I’ve been playing around a little bit now, trying to build a resizeable UIComponent around it and implement measure() and updateDisplayList(), and that’s what I’ve come across:
- when I set the width, the height always remains 0.
- getBoundingBox().width and height are o.k., but there update asynchronously, when you render the TextField. It would be nice if there would be an event to listen after the TextField is rendered.
- I don’t seem to be able to change the width once after style and text have been set – although it’s rendered again, there’s no change in the appearance and in the boundingBox.width/height either. Is this supposed behaviour?

Looking forward to your next postings!

- David

Wondered if you could help me as your tutorials are the only place I have found any good TLF info…

When I modify a TextElement.text property from it’s default the change is tracing out but the TextElement does not display the new String. Do I have to update the TextBlock or TextLine in some way?

Thanks

Scott

Editing likely won’t ever make it in. Not because it’s impossible, or even particularly difficult, but because it’s tedious and time consuming. I just can’t spend time on it unless someone’s willing to pay for it. Not to say that editing in tinytlf won’t exist, but if it does, it’ll likely be in a commercial component or package of some sort. What can I say, I’ve gotta eat.

There’s nothing stopping you from writing editability into tinytlf yourself. Tinytlf gestures make it really simple to capture all the necessary interactions, then activate the proper editing behaviors. The bulk of the work really that involves manipulating FTE ContentElements and TextBlocks. That’s the tedious part.

The Times Reader shows the pagination I am after. You’ll see that the columns fit the current page height and width and the number of columns or the height of the columns adepts to the new dimensions when the container is resized. I think this is an essential requirement for columns to be the most useful because the user will never ever have to scroll from the bottom of a long column to the top of the next. Instead all columns on a (dynamic sizable) page can be read without scrolling and when the last column is read the reader simply requests the next page.

What plans do you have for editing. Is it on your road map for the 2.0 release? What time frame do you have in mind for that?

content editing

Editing is a doozy. I’ll have more of an explanation later, but it’s probably not going to be in 1.0.

columns that can be viewed per page

Can you elaborate on this? A paginating textfield? Interesting.

columns that can be balanced

This requires a second layout pass, which I’ve been considering adding… basically, before you render the TextLines, you have no idea of how many you’re going to end up with. Once you have them all there you’d have to go back and lay them out differently to auto balance.

straddle heads

This could be accomplished with a TextContainer that spans the length of the columns along the top.