Colored or shaded sections of code in the SE

[dunbarx]

I would love to be able to set the backColor of, say, lines 600 to 700 of a script in the SE. I know this could get out of hand, but it would be a pleasure to hilite sections of code so I can locate them more easily when scrolling.

I know that all handlers are listed, and one can go to them directly. But I am talking about sections within a single long handler.

Craig

[richmond62]

Dunno why this one "flips a bluey" when I attempt to execute it, especially
as the scriptEditor passes it initially:

Code: Select all

on mouseUp
   set the backGroundColor of the script of button "hls" to green
end mouseUp

this is also no good:

Code: Select all

on mouseUp
   set the backGroundColor of the scriptEditor of button "hls" to green
end mouseUp

I suppose at this point one should ask a very direct question:

Is a script in a scriptEditor window a scrolling list field?

[dunbarx]

Richmond.

Just so. The SE is just a stack. I love saying that.

One can set the backColor of just a portion of the vertical extent of the text of any field. So this works:

Code: Select all

set the backColor of line 5 to 10 of fld 1 of stack "RevNewScriptEditor 1" to "red"

But this requires an external gadget to do so and the color does not stick. I want to have that gadget inside the SE. In other words, select a portion of the SE text, and then open a color wheel to select a color, and then HAVE IT SAVED.

Craig

[richmond62]

I want to have that gadget inside the SE.

Sounds good.

[dunbarx]

I opened a thread in the "feature Request" pane:
viewtopic.php?f=6&t=33578

which made me wonder why some properties (like the text) of the SE are saved between sessions, but something like:

Code: Select all

set the backColor of line 5 to 10 of fld 1 of stack "RevNewScriptEditor 1" to "red"
save stack "RevNewScriptEditor 1" 

is not. Just wondering...

Craig

EDIT.

"Between sessions" refers to having the SE closed and re-opening. One can set the backColor of one tab of several and close it. As long as the SE is still open at all, reopening the original tab will still show the colored text. But close the SE itself, and the property is reset to empty.

[Klaus]

Hi Craig,

all (new) script editor windows/stacks are CLONED from an original stack, which I don't know the name of.
So you have to edit THAT stack to make any changes "stick".


Best

Klaus

[dunbarx]

Klaus.

Thanks, I think I heard about that a while ago.

Since the SE is just a stack, I can:

Code: Select all

 answer the selectedChunk  of fld 1 of stack "RevNewScriptEditor 1"

No problem. And if I set the backColor of several sections of text, I can:

Code: Select all

 answer the htmlText  of fld 1 of stack "RevNewScriptEditor 1"

and store that somewhere. But even if I could save to that clone, it still is too cumbersome to use from "outside" the SE.

So it stays a feature request.

Craig

[FourthWorld]

You could make a plug-in that loads a frontscript which responds to a keystroke of your choice.

[dunbarx]

Richard.

I am currently setting colors of often-used sections of a long script by hand, to see how I like the overall effect. It makes finding the sections I am currently working on much easier to spot during scrolling. This, again, only sticks in the current SE session.

But I still am not sure how to save the effects between sessions. I assume that each script is saved separately in whatever master stack Klaus mentioned, so that in a new session, reopening any script shows its current state.

The htmlText of each script is saved, since the colors of the various states of text are. For example, the foreColor of text following a comment. But it seems that the backColor is not. It would not be so bad to set these by hand as I am working, if only they came back the next day.

Craig

[FourthWorld]

The script property itself is plain text. So if you want to store an htmltext copy you'll have to work out how to keep them in sync.

Htmltext does include the backgroundColor where set; indeed, htmltext was designed to reproduce everything in styled text with complete fidelity. I won't be able to know why it's not showing there without a sample stack or code.

[richmond62]

Well, up to a point.

Text size is not maintained:
-

[FourthWorld]

1. HtmlText is not HTML. Very different goals for each. HtmlText exists solely to provide a text representation of a all field contents with complete fidelity needed to reproduce them in another LiveCode field. Attempting to view htmlText in a web browser expecting HTML will sometimes produce something similar to what you'd hoped for, but often not. You can test the completeness of htmlText by setting the htmlText of another field to the htmlText of your sample field.

2. HtmlText will only include properties within the text itself, not field properties. If no text run within the field has had its textFont or textSize assigned, it will render with the textFont and textSize of the field the text is in. While those field properties will affect appearance, they are not part of the text within the field, and therefore will not be part of the htmlText representing the styled text.

[richmond62]

Presumably that means that LiveCode cannot export HTML.

[FourthWorld]

Presumably that means that LiveCode cannot export HTML.

Yes. HtmlText serves a very different goal from HTML.

In fact, there was a time when the team was considering changing the name of the property to something like "xmlText", to better clarify its unique role within LC, and that it's HTML-like but isn't true HTML. Alas, they have a reputation for maintaining greater backward compatibility than most scripting engines and they want to protect that, and "xmlText" is still not quite the best term given some of the nuances of both htmlText and XML. So for better or worse, the property remains named "htmlText".

That said, one can massage htmlText to become web-ready HTML. A lot of the work I do involves that.

When HTML is the output, depending on what you're doing with it starting with htmlText is a good foundation. But for a wide range of other tasks involving manipulating styled text, I can't say enough good things about working with a field's styledText array. Like anything else, it takes a little practice to get the hang of, but once you do it's such a clean an efficient way to process styled text runs.

[[-hh]]

HtmlText will only include properties within the text itself, not field properties. If no text run within the field has had its textFont or textSize assigned, it will render with the textFont and textSize of the field the text is in. While those field properties will affect appearance, they are not part of the text within the field, and therefore will not be part of the htmlText representing the styled text.

LC returns inherited properties when using the attribute "effective".
So yes, those field properties are not part of the htmltext. But they are part of

Code: Select all

the effective htmltext of <field>

Whether this generated code translates to similar display in browsers is another story...