Re: Screen colors

[cld@xxxxxxxx (Carl Distefano)]

Reply to note from Patricia M Godfrey  Mon, 21
Feb 2005 15:10:12 -0500

> Unfortunately, it won't change as you change your values (with
> the Default LX=NN,NN, and so on command), but you can just
> abort and recall to get the new values displayed.

Simply command FUNC FF (or toggle to the alternate screen, and back)
to refresh the display.

> (Maybe someday I'll add a routine to write the values to a text
> file that could be cut and pasted into settings.dfl; that would
> be simple enough, it's the trapping loops to know when you've
> finished tinkering that would be tricky.)

You don't need a loop to do that, Patricia -- although a loop would
be more concise (but not necessarily faster). RUNCODE examples 1)
and 2) below (DeFine each routine -- separately, of course -- and
issue RUNCODE). Each writes the current L0-L4 settings in
PRinter-file format. 1) is straight-forward; 2) uses a loop. You
can learn a good bit of XPL by comparing and contrasting these two
examples.

When you've mastered those, move on to example 3). It does the same
thing, but faster (about 10 times as fast as 1) or 2), not that
speed matters much for this task) and without setting Insert typing
mode (func SI). It uses the same loop as in 2), but instead of
PVing output to screen piecemeal, it appends each segment of output
to a Save/Get (+...>) and writes the whole thing at the
end (). (GT always inserts text; PV conforms to the current
state of Insert|Overstrike.)

XPLeNCODE v2.0
b-gin [UNTITLED]
;*; 1) No loop[cr|lf][GT_][SI_];[cr|lf]df L0={<}SX01,{<}VAL0{
>}{>}{<}PV01{>}[cr|lf]df L1={<}SX01,{<}VAL1{>}{>}{<}PV01{>}[c
r|lf]df L2={<}SX01,{<}VAL2{>}{>}{<}PV01{>}[cr|lf]df L3={<}SX0
1,{<}VAL3{>}{>}{<}PV01{>}[cr|lf]df L4={<}SX01,{<}VAL4{>}{>}{<
}PV01{>}[cr|lf];[cr|lf]{<}EX{>}[cr|lf][cr|lf];*; 2) Loop[cr|l
f][GT_][SI_];[cr|lf]{<}SX02,0{>}{<}LBa{>}{<}IF{<}PV02{>}<5{>}
df L{<}PV02{>}={<}SX01,"{<}VAL"+{<}IS02{>}+"{>}"{>}{<}SX01,{<
}PV01{>}{>}{<}PV01{>}[cr|lf]{<}SX02,{<}PV02{>}+1{>}{<}GLa{>}{
<}EI{>};[cr|lf]{<}EX{>}[cr|lf][cr|lf];*; 3) Loop (optimized f
or speed; avoids func SI)[cr|lf][GT_]{<}SV03,;[cr|lf]{>}{<}SX
02,0{>}{<}LBa{>}{<}IF{<}PV02{>}<5{>}{<}SX01,"{<}VAL"+{<}IS02{
>}+"{>}"{>}{<}SX01,{<}PV01{>}{>}{<}SX03,{<}IS03{>}+"df L"+{<}
IS02{>}+"="+{<}IS01{>}+"[cr|lf]"{>}{<}SX02,{<}PV02{>}+1{>}{<}
GLa{>}{<}EI{>}{<}SX03,{<}IS03{>}+";[cr|lf]{>}{<}GT03{>}{<}EX{
>}[cr|lf][cr|lf]
-nd
XPLeNCODE

When all is said and done, there's nothing wrong with method 1). It
gets the job done. In fact, it's slightly faster than 2) -- and, as
code, a lot easier to understand. A curious feature of XPL (and
probably other interpreted languages as well) is that a prolix,
repetitious, "inelegant" coding method is not necessarily slower
than a concise, structured, "elegant" one -- quite the contrary, in
some cases -- at least for simple tasks. In complex programs, the
need for concision becomes more compelling; little inefficiencies
multiply, and program size can be a drag on speed. But with the
little stuff, there's a lot to be said for keeping it simple.

--
Carl Distefano
cld@xxxxxxxx