[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: Xy program doesn't run in NB
- Subject: Re: Xy program doesn't run in NB
- From: Harry Binswanger hb@xxxxxxxx
- Date: Wed, 12 Sep 2007 12:56:00 -0400
The opposite: U2 *needs* to act differently between Xy4 and NB,
but doesn't! Func DX suppresses the result in NB -- I thought I
mentioned that to you maybe three days ago.
Yes, and I made, immediately, the change you suggested. I made it in both
the U2 for Xy and the U2 for NB, by copying the file from the Xy directory
over to the NB directory. So the two FileInfo frames perforce matched exactly.
But--and here's where it does get interesting--there was a typo in the
frame, and that typo had no results in Xy (hence went undetected) but the
same typo in NB produced the result that FileInfo gave only the path. I
think that's interesting and has consequences for XPL programming for NB
(only I don't know what those consequences will turn out to be).
The typo was an accidentally doubled quote mark, per the fragment below:
XPLeNCODE v2.0
b-gin [UNTITLED]
[Q2_]{<}IF{<}VA$VE{>}<>""V4.1"{>}[DX_]{<}EI{>}
-nd
XPLeNCODE
So Xy can deal with the typo, but NB can't. Further testing reveals that
the typo by itself is okay with NB, it is the interaction with some other
code in FileInfo that is responsible. I've done a little testing before
that operator is called, and in NB it gets the directory okay and DeFines
the correct line. I'm wondering if it's the "contains" operator, which is
rather new to XPL and is called twice. At any rate, if you run TEST.PGM,
below, which is adapted from FileInfo, you should see that Xy and NB
produce the different results. It's best to have two copies of TEST.PGM,
one for the Xy directory and one for NB, and then run it from each while
open in each.
My money is on the "contains" operator: it seems that the parsing is going
awry.
Harry Binswanger
hb@xxxxxxxx