Browse lookup

[Brian K. White]

Jay R. Ashworth wrote:
> On Wed, May 26, 2004 at 09:29:39PM -0400, Kenneth Brody wrote:
>> GCC Consulting wrote:
>> [...]
>>> To see why this was happening, I checked the product master for
>>> this item.  What I found was the in the description field, which is
>>> displayed in the browse, it contained ...L\I CD.  The color change
>>> occurred at the L\I.
>>>
>>> The other thing I found was that for other backslash combinations
>>> the backslash was deleted from the display.
>>>                 Tex\Trix
>>>                 Tuf\Trix
>>>
>>> Have any of you seen this?
>>
>> How else could you embed backslash codes?
>>
>> If you want to disable this handling within browse lookups, set the
>> config variable PFBRWSLASH=OFF.
>
> 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.

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.

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...

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani