Browse lookup

[Brian K. White]

GCC Consulting wrote:
> Had an odd thing occur today while testing a new program.
>
> While doing a browse lookup to a product master, I noted that when I
> scrolled down the list of items, one of them had part of the display
> in yellow.  When the highlight bat hit that item, the yellow area
> turned high intensity white (normal color is magenta).
>
> 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?

Not lately but it would fall under expected/defined behaviour by me.

Similarly to the way I clean out quotes from fields the might contain them
during a export to csv, I would just make a little one-line gosub and use it
(sparingly) on any fields that might need to be cleaned on the way to the
display.

my csv export goes like this:

...
7 If: 'company
Then: n=12 ; gosub clean ; csv(4)=n
...
26 clean If: '**************************************************************
Then: n = xlate(n,chr("34"){chr("13"),"'") ; return


That does two things at once, it changes " to ' and removes any carriage
returns

you would do something like, put n in the browse display instead of your
real field (say it was 12) and put a line like this in browse processing:
n = xlate(12,chr("92"),"/")

that would change the display from blah\blah to blah/blah

I would like to know if there was a reasonable for you to display the real
data myself. What if swapping \ for / isn't acceptable?

I know there are ways to show and show popup and system strings with
backslashes but they all involve assembling the string out of seperate
variables and litterals right on the action line so that the actual command
ends up interpreting harmless combinations of "\ " backslash-space, which
ends up leaving the backslash alone so it gets displayed. But then the
string also has  { aa  right after that, which closes up the space so the
resulting display or system command has what you want but it's assembled
_after_ the show or system command has already made it's pass through
looking for backslash-codes.

I don't know if you can do a trick like that in a browse display definition.
If you did it into a variable and put the variable in the display, you'd
just wind up with the same result you have now I think. But, worth a try.
maybe assembling the string inside browse processing will make the
difference. In your case it's going to be a pain though because first you
have to use instr and mid to chop up a single field into two fields so that
you can then re-assemble them with a space after the \ and a { after that.
p=instr(12,chr("92"),"1")
n=mid(12,"1",p) & " " { mid(12,p+"1",len(12)-p)

bahh, I can't beleive putting this in browse processing and putting n on the
browse display would be any different than just putting 12 on the browse
display directly.

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