If you draw to a region then draw the region to the screen, it should automatically clip any overflow.
Thanks for the tip, but I'm sorta in a paradox on this one. I haven't yet proven that anything greater than 80 chars is clip-able or for that matter necessary to show at all. Granted having it go outside my textbox and out the side of the screen isn't a solution. I just haven't decided if I'll manually insert a CR, LF, CRLR ( or is it LFCR? ) If I do that, then I have to count the lines being shown in the textbox differently or create a backup copy of the original data and not skip lines when moving up and down, when the wrapped lines scroll off the screen. I'm not converting the whole data and formatting it for my textbox control. I'm culling the lines I don't need and sending off the shortened roList. Decisions. decisions.
FWIW, since the data is a roList of strings, I'd just take the first 80 chars that way.
If you just define the roScreen as 1280x720 and pretend there is no SDTV mode, the hardware will take care of it for you.
Is that enough to pass certification?
Similarly, how often are we allowed to update our app after it is published?
... and no vertical scroll-bar / visible clue as to where in the text we're at
That should not be too difficult to do
Oh, but my talent lies in making things difficult!
Knowing what line I'm on and how many lines there are gives a percentage and via that we can drawRect() where it needs to be... just need a little more functionality as the data is not static. IOW, the size of the scroll bar widget thing.
Again, I agree, not too difficult. Just dealing with prioritizing tasks. First looking into changing the resolution to 1280x720 and see what falls off the screen and then change *all* objects to use relative screen positioning ( just in case the screen resolution needs to be changed in the future ). Also, the same method is being called for both my textbox control and my menu control... but doable. Totally doable.
take a look at roAudioResource. Sound effects are pretty easy, limitations are you need to use very small 16bit .wav files for your effects.
Yes, thank you. I've been using the Snake SDK example for some insights.