Request for character wrap (not word wrap) in fields

[ramav]

Please help: I cannot debug anything on the Internet when i have long GET and POST requests without spaces that I need to store and look at in fields!!! [A horizontal scroll bar helps, but it is really not a good workaround since I need to be able to look at the entire string when I am trying to figure things out...)]the request below (and thread) seems to have started in 2002... many thanks in advance


Recently (2002!), Brent Neal wrote:
>
>>>> Is there something odd with wrapping in text fields in the OS X version?
>
>>> Does the text have spaces in it?
>
>> No. I just tapped at random keys (i.e. asdfasfdasdf). Consider
>> SimpleText. If you hold down a single key, when it reaches the text
>> field width, it starts over on the next line. That shouldn't matter.
>
>Unfortunately, wrapping lines of text in MC/REV requires that there be
>spaces among characters.

[Joe F.]

I'd like to revive this thread.
Text wrap in a field isn't something I should have to code to accommodate lines with no spaces. It should just wrap within the field with a choice of word OR character wrap.

This should also make possible soft wrap within the script editor. In another post on the forums some of the veterans spoke out against this as making code less readable, but they missed the point.

In the script editor you should be able to toggle soft wrap just so you can see what's there without having to scroll. You toggle it off when you want to see pretty code.

How hard can it be to do this?

[ramav]

I agree wholeheartedly--this is a major flaw making the use of Livecode as a frontending tool (my main use for LiveCode currently is to interface as a GUI to all the myriad APIs) almost impossible. More importantly, regardless of what the "veterans" say, the current LiveCode behavior is nonstandard, why even look at.this.screen.where.i.have.typed.in.a.long.sentence.continuously.without.word.breaks.yet.it.wraps.beautifully.as.soon.as.it.reaches.the.edge.of.the.window.which.is.the.way.all.word.processors.including.gold.standard.MSWord.work!

[ramav]

Ahem :..at least it did as I was typing it in!!

[Simon]

Too funny

[Joe F.]

Well, irony is usually funny, but this is a case of oversight by whoever did the CSS for this forum and is
easily fixed by toggling a single parameter… (word-wrap: break-word;)

In LiveCode the only "fix" would be counting out characters to insert line breaks, and then removing them when you're done with them. In other words: creating a hard wrap.

We should definitely have a character-wrap option in field objects and the script editor.

[Simon]

I don't ge
t how this cou
ld be mor
e fun.
Maybe there is a good reason.

Si
mon

[richmond62]

I've just had a look at DONTWRAP and it only works
for WORDS.

The documentation (7.0.3) states that dontWrap was changed at version 5.5

BUT looking at the documentation in version 4 I cannot see what the difference is.

This is a BIG problem: stating that something has changed, but not HOW it has changed.

THIS is interesting: https://support.apple.com/kb/TA44432?lo ... cale=en_US

"Word Wrap: Word wrap has been changed so only a space character will break
up a word at the end of a line. In past versions, HyperCard would break
any string with punctuation at the end of a line."

Not that that entailed character wrapping.

THIS is also interesting: http://www.supercard.us/new/index.html

"Enhanced User Property Editor
A new “Soft Wrap” checkbox allows you to wrap non-breaking lines in the contents
field for easier editing, and both horizontal and vertical scrolling is now supported
for scroll-enabled pointing devices."

[Joe F.]

Before long you will have to deal with long, unbroken strings of text that you must read and/or generate within your app.
Indeed, a large portion of the code to run things on the internet these days is machine generated and encoded, but that is just one (huge) example of a case where you might need to inspect a string that would cause a LiveCode field to scroll many times its width. For example, an excerpt from a random YouTube page:

Code: Select all

Do-AG0XMg1by80RFiR-wcBCmSqbDVT3FQp2XDq3IpOiHQZH%26requiressl%3Dyes%26dur%3D1502.268%26mm%3D31%26pl%3D22%26source%3Dyoutube%26fexp%3D907263%252C927622%252C937412%252C9405997%252C9406841%252C9407000%252C9407430%252C9407433%252C9407440%252C943917%252C948124%252C948905%252C951703%252C952302%252C952612%252C952901%252C955301%252C957201%252C959701%252C964731%252C965300%26ms%3Dau%26mt%3D1425838114%26mv%3Dm%26lmt%3D1392632478925151%26sver%3D3%26itag%3D136%26initcwndbps%3D1697500%26sparams%3Dclen%252Cdur%252Cgir%252Cid%252Cinitcwndbps%252Cip%252Cipbits%252Citag%252Ckeepalive%252Clmt%252Cmime%252Cmm%252Cms%252Cmv%252Cpl%252Crequiressl%252Csource%252Cupn%252Cexpire%26ipbits%3D0%26expire%3D1425859803%26gir%3Dyes%26clen%3D174737024%26keepalive%3Dyes%26mime%3Dvideo%252Fmp4%26signature%3D926428286D59A69E01114091DF79DD4477B4CB6D.32F36C006BABC2DA6E8E4DE36C818590D219A3F5%26key%3Dyt5%26ip%3D24.186.249.90%26upn%3DMJvPLaAIWQU\u0026bitrate=1210744\u0026index=709

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.
Okay… now try to select a portion in the middle of the string. It ain't easy. You would have to do some pretty fancy coding to make this functional for your users.

It's just not standard to have a field that can hold more than it displays and not have a way to display it. Inserting line breaks? Then how do you undo that? You'd have to create a separate display and keep track of the differences. All that just to get the standard expected behavior that a novice LiveCoder would expect to be a "given".

LiveCode has more than a few of these annoyances. You can spend hours searching for an answer and saying "what am I doing wrong?"; then it turns out the answer is "that's just the way it is".

In another forum topic a few people defended the "no wrap" standard in the script editor as making code more readable because the logic was clear from the beginnings of each line. They neglected the idea that sometimes it's just as important to see the whole line at once (rather than have to scroll), and that the desirable way to handle wrapping would be as an on/off toggle.

It just seems like something that should have been fixed years ago.

[richmond62]

One of the things that worries me is that if one looks at the prefs palette for a textBox:

one can see the property textHeight,
BUT there is no property 'textWidth', because, if there were
it should be comparatively easy to implement a character wrap:

(width of fld "FLD") / textWidth = number of chars before one wraps.

[dunbarx]

I miss the old HC xfcn "wordWrap". But even this was, though it could be implemented in one line, an add-on, and could not be undone without just a bit more coding.,

I vote again here that a char wrap, as a field property, is likely a very needed addition to LC. Don't change the legacy functionality with regards to spaces, just add the property.

Craig Newman

[richmond62]

Yes, Craig, that gets my vote too.

It wasn't until I was in the bath just now that I realised the problem with a theoretical 'textWidth':
most fonts are NOT fixed width ones any more [fond memories of MONACO on Mac OS 7].

[dunbarx]

Richmond.

Have you ever played with the "measureText" function?

Craig

[Joe F.]

Line height is mandatory otherwise you wouldn't be able to accommodate resizable fonts. Character width is a bit more esoteric, only apps that are taking responsibility for rendering each pixel are going to give you that kind of functionality.

It's notable that there are all kinds of functions for reading the formattedwidth and the measureText etc., but what do you do with those functions? You have to either resize the field, or the font, or break down the text for wrapping programmatically.

It should just wrap.
I'm not even asking for hyphenation, which is what you'd expect with character wrapping.

As it is I need to have TextWrangler open whenever I'm working with long strings in LiveCode.

It's possible that the forthcoming HTML5 rendering will make this issue disappear, but I had hoped the "new" field and text handling capabilities would resolve these obvious issues a long time ago.

[FourthWorld]

Joe, in the YouTube example you posted, what were you looking for, and what did you find?