LiveCode Forums.

The dontWrap on a field only handles word chunks, not character level text, is that correct?

For instance, if you have say, and the word 'lamb' was past the edge of the field, that would wrap.

If on the other hand, you have and only the 'lamb' was past the edge of the field, it doesn't wrap, because it is one word instead of wrapping at the character level?

The dontWrap on a field only handles word chunks, not character level text, is that correct?

That is correct, so you need at least one SPACE to get your text wrapped.

Thanks Klaus, I couldn't find what made the determination readily.

Bogs.

This has been a subject of discussion forever, that a space, and not simply the width of a field, determines wrapping. There are a bunch of kluges using the formattedWidth, formattedText and actual text properties to be able to force line wrapping in unspaced text.

The first one I ever did, centuries ago, relied on monospaced fonts like Courier. You can see, I bet, how simple that would be to implement. It is trickier with other fonts.

Craig

The good news is that for most practical needs this is rarely a problem, since all languages tend to have word breaks at a reasonable length.

So the issue tends to come up when displaying things that aren't readable text, which raises the question: if it's not for reading, why bother putting it into a field?

Once we learn more about the specifics of the task you want to accomplish we can provide good guidance on delivering your vision with acceptable effort.

dunbarx wrote: ↑

Sat Feb 16, 2019 5:57 pm

This has been a subject of discussion forever, that a space, and not simply the width of a field, determines wrapping. There are a bunch of kluges using the formattedWidth, formattedText and actual text properties to be able to force line wrapping in unspaced text.

Yah, I can believe it. I was a bit surprised that this was the default behavior, but probably shouldn't have been

It is probably the languages I come from that keeps fouling me up in this one. Delphi, for instance, wrapped based on a number of delimiters, just as Lazarus/FPC does ~ I wound up just setting a scrollbar if the formatted width exceeds the text area. I expected to have to do that for the height anyway, but for expediency went with the width as well.

FourthWorld wrote: ↑

Sat Feb 16, 2019 9:37 pm

So the issue tends to come up when displaying things that aren't readable text, which raises the question: if it's not for reading, why bother putting it into a field?

Well, like everything, there are the 'exceptions to the rule...', and this case is no different. Inspired by one of your posts to more fully explore creating text editors, I was testing opening different files. In this case, the file had an extremely long URL in it, which of course has no spaces, but is certainly readable and may even be desirable to read.

Other languages I am more used to handle this differently than Lc does (as mentioned above), but even common text editors tend to handle it the same way. Here is a shot of the project in Lc, vs. the file in Pluma ~ As you can see, Pluma, much like the Laz IDE, tends to wrap based on whatever it determines to be a reasonable delimiter, in this case, it wraps at the '/', but it will also wrap at other things, such as a '-' or space or even a '\' but not, suprisingly, a period if no space is on the other side

In Pluma, though, it isn't going to just wrap no matter what, if you have a single line of characters with no interruption, it will do as Lc does, and introduce a scrollbar. That is, as I said, behavior I think of as 'normal' or 'expected'.

Ultimately, my question was more towards my education than needing a solution, as Craig mentions there are a hundred ways to handle it. I'm not sure I'd call them kludges though, as the ones that come to the top of my head are legitimate uses of the language. I guess I just expected the most common ones to be 'baked in'

Yep, different programs do different things. Though LC does a poor job when it's asked to display uncommonly-long words, it shines with inline and paragraph styling, super-efficient buffering, and many other features shipping apps rely on.

Exploring the edge cases that define the boundaries of the LC engine can sometimes yield useful outcomes. The URL is an interesting case here. It may be good to include that in the enhancement request.

How's the rest of your text editor coming along?

FourthWorld wrote: ↑

Sun Feb 17, 2019 7:32 pm

It may be good to include that in the enhancement request.

How's the rest of your text editor coming along?

I would, if I thought it needed enhancing. Once you know what triggers what, though, it is handled easily enough

The text editor *might* show up as a tutorial at some point (I've got a lot on the stove at the moment and probably for the next several months, so not tomorrow for sure).

When I started using Delphi (back around vers. 5) They had a very good and thorough introductory tutorial using, of all things, a text editor as the goal. Among other things, it introduced creating menus, using images/action lists, scaling controls (although this is much more consistent and easy in Delphi, to me at least), and so on.

Working through this, I see it eventually being a good chance at providing not only me with an education, but possibly someone else at a later date. As a whole project, it is certainly easier than the text editor was in Delphi for a similar result (so far).

Whether I can take what I'm learning and boil it down to a logical set of steps for someone else to learn from or not is going to really be a challenge.