Browse lookup

[Jay R. Ashworth]

On Thu, May 27, 2004 at 01:06:13AM -0400, Brian K. White wrote:
> > If I correctly understand all the pertinent data, I submit that this
> > constitutes the programmers of browse lookup confusing the requirement
> > to evaluate \ escapes in the *format*, with the extremely unlikely
> > event that someone would want such escapes in the data being
> > interpreted -- I don't believe that any *other* data display routines
> > interpret such escapes in the data they display; do they?
> 
> Generally the only use for color/inverse codes in a browse display is so
> that certain records and/or certain fields can be dynamically highlighted
> depending on their content.
> 
> You can't alter some lines and not other lines any other way than by putting
> the codes into fields and putting the fields in the format.

Certainly you could: redefine some *other* format code to mean "display
this dummy, possibly interpreting \-escapes.  Like, oh, %, which has no
other real use in a browse lookup format.

> The only way fp could reasonably distinguish between data and formatting
> codes is to maybe adopt a rule that states that the codes are ignored in
> real fields but parsed in dummies and if placed directly in the format
> string.
> 
> Or maybe they could hijack some control character or high-ascii character
> and when that character is found in the browse format a "\" is actually
> displayed. Similar to how a : in a process table has to be a ctrl-a in the
> real file because the file is : delimited and the way *report uses the ascii
> characters from 0 to 10 internally and so they can't be used in an output
> format.
> It wouldn't be a new or inconsistent type of gimmick.

Not at all... but if the current state of affairs is unexpected
data-sensitivity, then I submit that the wrong default choice has been
made -- especially since Ken says there's already a knob.

> You could use xlate in browse processing as in my previous example to swap
> the real \ for the fake for display.
> 
> PFBBRWSLASH=off is too all-or-nothing for me since it would have to affect
> all browses for the duration of a clerk session.
> unless there is a processing command equivalent to turn it on and off. Not
> that I'm working on any dynamically colorized browses at the moment... but
> if I were...

Indeed; but see my other (constipated) reply about a system function
suggestion to modify the presentation of a field programmatically; that
would be applicable here as well.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Member of the Technical Staff     Baylink                             RFC 2100
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 647 1274

        "They had engineers in my day, too."  -- Perry Vance Nelson