LiveCode Forums.

That was just a random string I snatched to demonstrate the relevance of the issue to day to day coding here in the internet age. You can find similar unbroken strings in almost any web page.

But the point is not about parsing strings, it's about simply displaying them and using them within a field. Sometimes you need to see the lines of text, and sometimes you need to see the text itself. When I'm working in the script editor and want to copy a long line, it would be lovely to be able to flip on that soft wrap. And sometimes that extra comma that's screwing things up is 2 window widths away from the right edge of the window. Frustrating.

Joe F. wrote:

Copy the code above and paste it into a LiveCode field. The formattedwidth will be over 6000 pixels, that's a lot of scrolling and this is only about an eighth of the full text.

FWIW, this forum didn't wrap it either, nor did my email client, which is where I read the forum digest.

Joe F. wrote:When I'm working in the script editor and want to copy a long line, it would be lovely to be able to flip on that soft wrap.

FWIW, LC follows the convention common to all three desktop platforms in which a triple-click will select the entire line.

Richard.

FWIW, LC follows the convention common to all three desktop platforms in which a triple-click will select the entire line.

Interesting. So if by magic we suddenly had a field property that wrapped chars, would a triple-click hilite all such wrapped lines? It should, I guess. This sounds like a fun project to do in my spare time. By that I mean while I should be working.

Craig

dunbarx wrote:Richard.

FWIW, LC follows the convention common to all three desktop platforms in which a triple-click will select the entire line.

Interesting. So if by magic we suddenly had a field property that wrapped chars, would a triple-click hilite all such wrapped lines? It should, I guess.

In LiveCode and other programs that support triple-click to select the line, the action should select the string between CRs regardless how that string is rendered on screen.

This sounds like a fun project to do in my spare time. By that I mean while I should be working.

If you have time to play with it, it may be helpful to remember that in v5.5 (where so many paragraph-level attributes were added) and later 0x11 is rendered as a softwrap where the dontwrap is set to false. This allows visual line breaks while preserving the triple-click behavior.

If you need to justify the time for work, you might consider making it into a hex viewer, a two-column view that has the raw data in one and the hex values in another. Such a tool could be useful for examining byte streams such as the earlier example, where visual inspection would be difficult at best and would miss non-printable characters like NULLs.

So, as Craig suggested, I had a play with measureText:
Now, what I cannot work out is any connection between "83" and the width of the text field.

file deleted: new version "wrapt.zip" further down thread.

Richmond.

The "measureText" is the width in pixels of the text of a line in a field. If you subtract that from the Width of that field, you would get the width of the white space.

Craig

Why this opposition to expanding a limited field setting?
I'm not saying I don't want word wrapping, I just want character wrapping too!

The forum HTML wrapping I addressed earlier (there's a CSS setting for that).
No, the email client won't wrap it, but TextWrangler will - it'll wrap it any way you want.

Triple-clicking selects whole lines, okay. What if I want to select from the middle of a line that extends 200 characters past the field edge? If you have to do it a lot it gets tedious pretty quick. And try doing it in a locked field; you'll see some pretty weird behavior.

There are unbroken strings of text out there in the world, why should we be limited to vertical scrolling to see them?
In TextWrangler I'm constantly turning on soft wrap; I'd like the same functionality in the apps I create.

Joe F. wrote:Why this opposition to expanding a limited field setting?

I must have missed something. Who wrote that they were opposed to seeing this implemented?

Sorry if I misinterpreted noncommittal replies as defending the status quo. I'm more hoping for "yeah - me too!"


@richmond62

You forgot: "put fld "FEELD" into theText"

It gives you the pixel width of the the first parameter (theText).

Interestingly, it will give you the width of all the text in the variable as if it were one line, even if you have returns breaking it into multiple shorter lines.

Joe F. wrote:Sorry if I misinterpreted noncommittal replies as defending the status quo. I'm more hoping for "yeah - me too!".

There are a couple requests for this in the bug DB, so you're not alone. I could make use of it, but it's not a high priority for me. In my own work it's very rare that I have long unbroken bytestreams that I want to display to the user.

I'm not opposed to the feature either, just pointing out that it doesn't seem to be the norm as was stated.

But it's very low on my priority list, and isn't something I'd want the team to spend much time on. Outside of the script editor I can't ever recall needing to display unbreaking text that long. And inside the editor we already have a way to manually break long lines.

This kind of field might make a good widget for the next version of the engine.

Thank you Joe F. for putting me right there

Apple's TextEdit has no "unwrap" setting; it's character wrap until there's a space, then it's word wrap. Mail is the same.
So that's my sense of the "expected behavior".

I never add manual line breaks in scripts because most of the time I want to see the line beginnings in place.

I don't know that I have a priority list, but I've wanted this for years.
There's already word-wrap in place, so how long could it take?

Maybe I'm spoiled by having used text editors so much.