Large Text in Don't Wrap Field w hScroll

[Mark Swindell]

Hi. I'm encountering an odd situation. I'm placing a paragraph of text into a field with the Don't Wrap checked, and with an hScroll bar. The text is big, 160 pts. I am scrolling the paragraph via script, like a banner, but it's the same result manually. The deal is, after only a couple of sentences the text disappears. Can't be seen. There are no line breaks in the text. The full contents of the field are there in the inspector. Any ideas what may be happening? This is in RunRev Studio, and also LiveCode, same result. MacBook Pro, Mountain Lion. Shrinking the text gets me more words, so there is some sort of limit being reached here, but it seems wrong and far too small to be what ought to be. Two things have happened: In the first instance, the text simply disappears, and the field continues to scrolls, blank, or, in scenario 2, text reaches the end of its limit and the scroll is done, no more movement to the right. Insights would be appreciated.

Thanks,
Mark

[Simon]

What happens if you get rid of the hscroll and set the fld width to the formattedWidth and then move the entire fld?
Not really an answer to your question but maybe a workaround?
64K characters per line is the fld max.

Wow joined in 2006 and this is your first post!

Simon

[sturgis]

I think I may know whats up. When the text is in the field and you're scrolling through it, what is the formattedwidth? There are some weird things that happen when a line gets too long and since its a display problem and (I think) not a line length problem (maybe?) you might be hitting that issue.


If you are just running a marquee type of thing it might work better to cycle through the text in smaller chunks to avoid this issue.



EDIT: If the number of chars in the line is really long, that might be it too though as mentioned above, I think its a max field width display issue.

[Mark Swindell]

Thanks for the responses. The behaviors seem very much font-related. Seem like a bug. I wonder if such a thing has been documented in Bugzilla. The formattedwidth varies between 10k and 60k depending on font. Display swings wildly. Not much rhyme nor reason. Sometimes displays a dozen words, sometimes 40. Certainly a game changer in my small-niche need. And it doesn't seem related to whether there is an hScrollBar on the field. If anyone would want to try it out, it would be helpful. Just make a field, give it an hScrollBar, set the font to 160, the can'tWrap to true, and drop in a 50 word paragraph and scroll it. See how far you get.

Thanks again!
Mark

[Simon]

Hi Mark,
OK tested it and did get the error but then by pasting unformatted text into the contents it cleared up.

You are receiving this notification because you are watching the topic, "creating a work schedule program" at "LiveCode Forums". This topic has received a reply since your last visit. You can use the following link to view the replies made, no more notifications will be sent until you visit the topic.

was my test string, Arial was the font and 160 the size.

Simon
Edit: ooops, I doubled the test string and everything disappeared.

[sturgis]

Yep, pretty sure its the same issue. Look here: http://list-archives.org/2012/10/13/use ... 6333221509 think some of that applies. Its not the number of chars in the line its the width of the line itself thats the problem. I ran into this a while back when making a scroller and ended up cycling through the text poking text in at the back removing it at the front to make the problem stay away. I suspect this is one of those things that will probably be tweaked once things finally go open source. I have my fingers crossed at least.

If I recall, behavior gets really strange once you pass a certain pixel limit. (width of 32768) (and behavior changes if you turn dontwrap back off and still have a really really long line)

Also, 50 words may not be enough to pass the limit depending on which letters and word length. t, l, etc aren't as wide, GBLA are wider. However pretty much every time I get around the 400 char mark the problem pops up. formattedwidth is 32794 at the moment and it just broke. Its been there a while though not sure it can be called a bug since I think it was originally designed this way.

[Mark Swindell]

Thank you guys so much for checking this out! I can't help but think this is a bug. Not sure what you mean about it having originally been designed this way, sturgis. If you change fonts things get really mixed up. It seems like you ought to be able to hold a paragraph of text and scroll it at virtually any size. Perhaps not a bug, but poor design. I also hope the open source nature of the program will find someone willing and able to address it. Simon, will experiment with your solution. Thanks again for the help.

[jacque]

I believe it's a limitation in OS X, if that's the OS you're on. There is both a 64K character length limit per line, and a 32K pixel limit per line.

The solution, as sturgis mentioned, is to push characters onto the end of the string while they are still out of view, and remove them from the front after they scroll off.

[Mark Swindell]

I'm not sure my coding skills are up to the job of determining which characters are showing in the field as they are scrolled through. Is this something easy enough to calculate and operate on?

[sturgis]

Create a field and a scrollbar
Group them

In the code for the group put the following:

Code: Select all

local sHugeString -- local var to hold the huge text
setprop hugetext pString -- a virtual prop handler. There is no actual property for this i'm just using a local variable. 
   set the endvalue of scrollbar 1 to the number of chars in pString + 1 -- Sets the range of travel for the scrollbar to match the number of chars in the string + 1 
   set the thumbsize of scrollbar 1 to 1 -- set the size of the thumb thingy to 5. A nice manageable size. 
   put pString into sHugeString  -- save the string that was passed in to the local variable
   setTextPos -- call the setTextPos hander to set text position. 
end hugetext

on scrollbardrag pPosition -- when the scrollbar is changed, set the text position
   setTextPos
end scrollbardrag

command setTextPos
-- uses the thumb position of the scrollbar to choose position of the first char showing.
-- then does the same but adds 50 chars (any number long enough to ensure the field is filled
-- but short enough to avoid the display issue should work. 50 is just a random choice I made. 
-- once the chars are selected, simply put them into the field.  The first will always be at the left.  
-- and it seems to fall through gracefully if there aren't 50 chars left following the first char chosen. 

   put char (the thumbposition of scrollbar 1 of me) to (the thumbposition of scrollbar 1 of me + 50) of sHugeString into field 1 of me
end setTextPos

This was just a quicky hack, there are probably issues with it, but hopefully will get you started on a track that will do what you need.

EDIT: Might need to tweak how the scrollbar behaves a little to make things more controllable with large amounts of text. Probably scale up the endValue by a factor then do some math on the position to descale and round to get the right positions but I'm not seeing an optimal solution at the moment so won't muddy things any further. The code already posted is close.

[Mark Swindell]

Thank you, sturgis, looks promising. I'll work from that and see how it comes out.

Mark

[sturgis]

Just re-read your first post. If you're doing this under program control with no scrollbar its much easier.

Store the text somewhere.
Have a working storage container (variable or whatever)

put the first 50 chars into the field (or 20 or 30 or whatever)

So if your working text is in variable myText
your loop could do something like
put char 1 to 50 of myText into field "myfield"
put char 1 after myText
delete char 1 of myText (move char 1 to the back)

next loop it'll put the first 50 chars of the adjusted text into the field. This will lead to a nice perpetual loop of the text if thats what you're looking for.