Page 1 of 3
Colored or shaded sections of code in the SE
Posted: Fri Jan 24, 2020 7:22 pm
by 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
Re: Colored or shaded sections of code in the SE
Posted: Fri Jan 24, 2020 8:52 pm
by 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?
Re: Colored or shaded sections of code in the SE
Posted: Fri Jan 24, 2020 9:43 pm
by 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
Re: Colored or shaded sections of code in the SE
Posted: Fri Jan 24, 2020 9:58 pm
by richmond62
I want to have that gadget inside the SE.
Sounds good.
Only some of the SE properties are saved between sessions
Posted: Fri Jan 24, 2020 10:22 pm
by 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.
Re: Only some of the SE properties are saved between sessions
Posted: Fri Jan 24, 2020 10:32 pm
by 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
Re: Only some of the SE properties are saved between sessions
Posted: Fri Jan 24, 2020 10:44 pm
by 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
Re: Colored or shaded sections of code in the SE
Posted: Fri Jan 24, 2020 11:07 pm
by FourthWorld
You could make a plug-in that loads a frontscript which responds to a keystroke of your choice.
Re: Colored or shaded sections of code in the SE
Posted: Fri Jan 24, 2020 11:23 pm
by 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
Re: Colored or shaded sections of code in the SE
Posted: Fri Jan 24, 2020 11:45 pm
by 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.
Re: Colored or shaded sections of code in the SE
Posted: Sat Jan 25, 2020 9:17 am
by richmond62
Well, up to a point.
Text size is not maintained:
-
Re: Colored or shaded sections of code in the SE
Posted: Sat Jan 25, 2020 9:32 am
by 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.
Re: Colored or shaded sections of code in the SE
Posted: Sat Jan 25, 2020 9:43 am
by richmond62
Presumably that means that LiveCode cannot export HTML.
Re: Colored or shaded sections of code in the SE
Posted: Sat Jan 25, 2020 11:03 am
by FourthWorld
richmond62 wrote: ↑Sat Jan 25, 2020 9:43 am
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.
Re: Colored or shaded sections of code in the SE
Posted: Sun Jan 26, 2020 2:43 pm
by [-hh]
FourthWorld wrote: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
Whether this generated code translates to similar display in browsers is another story...