Duh - replying to myself again :-)
It looks as though that's exactly what you do mean - it certainly
generates the problems you described earlier. And my one-line additional
test would (does in my testing) solve it properly - without it, we don't
get a chance to flush "theInsideStringSoFar" to tNuData, with the extra
line we do. And adding it is always safe (AFAICI).
-- Alex.
On 17/10/2015 00:03, Alex Tweedly wrote:
Sorry, Mike, but can you describe what you mean by a "naked" line ?
Is it simply one with no line delimiter after it ?
i.e. could only happen on the very last line of a file of input ?
Could that be solved by a simple test (after the various 'replace'
statements)
if the last char of pData <> CR then put CR after pData
before the parsing happens ?
-- Alex.
On 16/10/2015 17:19, Mike Kerner wrote:
No, the problem isn't that LC use LF and CR for ascii(10) and ignores
ascii(13). That's just a personal problem.
The problem, here, is that the csv parser handles a naked line and a
terminated line differently. If the line is terminated, it parses it
one
way, and if it is not, it parses it (incorrectly) a different way, which
makes me wonder if this is the latest version.
On Fri, Oct 16, 2015 at 11:28 AM, Bob Sneidar
<bobsnei...@iotecdigital.com>
wrote:
But what if the cr or lf or crlf is inside quoted text, meaning it
is not
a delimiter? Oh, I'm afraid the deflector shield will be quite
operational
when your friends arrive.
Bob S
On Oct 16, 2015, at 08:04 , Alex Tweedly <a...@tweedly.net> wrote:
Hi Mike,
thanks for that additional info.
I *think* (it's been 3 years) I left them as <GS> (i.e. numtochar(29))
because I had some data including normal TAB characters within the
cells
(!!( and thought <GS> was a safer bet - though of course nothing is
completely safe. It's then up to the caller to decide whether to do
"replace numtochar(29) with TAB in ...", or do TAB escaping, or
whatever
they want.
As for the other bigger problem .... Oh dear = CR vs LF vs CRLF ....
Are you on Mac or Windows or Linux ?
How is the LF delimited data getting into your app ?
Maybe we should just add a "replace chartonum(13) with CR in pData" ?
(I confess to being confused by this - I know that LC does
auto-translation of line delimiters at various places, but I'm not sure
when it is, or isn't, completely safe. Maybe the easiest thing is to
jst do
all the translations ....
replace CRLF with CR in pData
replace numtochar(10) with CR in pData
replace numtochar(13) with CR in pData
-- Alex.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
