CHR(10) embedded in Memo fields

[Dan Musicant]

This is for me a head scratcher. I'm using VFP 9.0 (possibly on FPW 2.6
compatible tables), and have a memo field that includes dates. The dates
have been converted to strings with the DTOC function. Many of the
entries in the field have multiple dates to which I've concatenated
CHR(13). So, for instance, one entry is:

10/20/2009
04/11/2008
09/30/2006
04/30/2006
04/28/2006
04/27/2006
04/26/2006
04/24/2006
04/22/2006


The edits to the memo field are usually done by code, not by manual
edits. What I'm finding, however, is that if I go in there and make a
manual change, theres an extraneous character inserted multiple times in
the field, being CHR(10). This causes output to my messaging function to
look strange with a black character. I've done a STRTRAN() against the
field in the Command Window to correct the problem:

REPLACE ALL lastwatchm WITH STRTRAN(lastwatchm,CHR(10),'')

This has fixed the problem. However, I'm wondering why CHR(10) is
getting in there in the first place and if there's something I can do to
prevent it from happening in the future other than embedding my fix in
recurring code.

Dan



Email: dmusicant at pacbell dot net

[Gianni Turri]

Hi Dan,

a manually inserted CR consists of:

chr(13) + chr(10)
alias
CR + LF
alias
h0D h0A exadecimal
alias
Carriage Return + Line Feed

Any ASCII editor put this pair of characters when you insert a CR.

VFP messaging functions should have no problem to treat this pair like a simple chr(13).

Try in the command window.

What code do you use to extract the lines from the memo field?

It is better to use mline() or alines() who care to remove chr(13) or chr(13) + chr(10) whatever is there.

Gianni

On Fri, 28 Jan 2011 09:41:27 -0800, Dan Musicant <***@privacy.net> wrote:

This is for me a head scratcher. I'm using VFP 9.0 (possibly on FPW 2.6
compatible tables), and have a memo field that includes dates. The dates
have been converted to strings with the DTOC function. Many of the
entries in the field have multiple dates to which I've concatenated
CHR(13). So, for instance, one entry is:

10/20/2009
04/11/2008
09/30/2006
04/30/2006
04/28/2006
04/27/2006
04/26/2006
04/24/2006
04/22/2006


The edits to the memo field are usually done by code, not by manual
edits. What I'm finding, however, is that if I go in there and make a
manual change, theres an extraneous character inserted multiple times in
the field, being CHR(10). This causes output to my messaging function to
look strange with a black character. I've done a STRTRAN() against the
field in the Command Window to correct the problem:

REPLACE ALL lastwatchm WITH STRTRAN(lastwatchm,CHR(10),'')

This has fixed the problem. However, I'm wondering why CHR(10) is
getting in there in the first place and if there's something I can do to
prevent it from happening in the future other than embedding my fix in
recurring code.

Dan

Email: dmusicant at pacbell dot net

[Dan Musicant]

On Sat, 29 Jan 2011 00:26:45 GMT, Gianni Turri
<***@andthisgmail.com> wrote:

:Hi Dan,
:
:a manually inserted CR consists of:
:
:chr(13) + chr(10)
:alias
:CR + LF
:alias
:h0D h0A exadecimal
:alias
:Carriage Return + Line Feed
:
:Any ASCII editor put this pair of characters when you insert a CR.
:
:VFP messaging functions should have no problem to treat this pair like a simple chr(13).
:
:Try in the command window.
:
:What code do you use to extract the lines from the memo field?
:
:It is better to use mline() or alines() who care to remove chr(13) or chr(13) + chr(10) whatever is there.
:
:Gianni

Thanks for the great info. I used ALLTRIM(Memofield) to extract the
lines. I wanted to retain the CHR(13) but not the CHR(10). Why is the
CHR(10) even there? Doesn't a CHR(13) include a line feed?

Dan


:
:On Fri, 28 Jan 2011 09:41:27 -0800, Dan Musicant <***@privacy.net> wrote:
:
:This is for me a head scratcher. I'm using VFP 9.0 (possibly on FPW 2.6
:compatible tables), and have a memo field that includes dates. The dates
:have been converted to strings with the DTOC function. Many of the
:entries in the field have multiple dates to which I've concatenated
:CHR(13). So, for instance, one entry is:
:
:10/20/2009
:04/11/2008
:09/30/2006
:04/30/2006
:04/28/2006
:04/27/2006
:04/26/2006
:04/24/2006
:04/22/2006
:
:
:The edits to the memo field are usually done by code, not by manual
:edits. What I'm finding, however, is that if I go in there and make a
:manual change, theres an extraneous character inserted multiple times in
:the field, being CHR(10). This causes output to my messaging function to
:look strange with a black character. I've done a STRTRAN() against the
:field in the Command Window to correct the problem:
:
:REPLACE ALL lastwatchm WITH STRTRAN(lastwatchm,CHR(10),'')
:
:This has fixed the problem. However, I'm wondering why CHR(10) is
:getting in there in the first place and if there's something I can do to
:prevent it from happening in the future other than embedding my fix in
:recurring code.
:
:Dan
:
:Email: dmusicant at pacbell dot net



Email: dmusicant at pacbell dot net

[Gianni Turri]

No.

chr(13) is a Carriage Return
chr(10) is a Line Feed

On an (old dot matrix) printer this becomes clear:

CR only Return the Carriage to the left

To advance one line a LF is needed.

Gianni

On Fri, 28 Jan 2011 17:40:09 -0800, Dan Musicant <***@privacy.net> wrote:

Thanks for the great info. I used ALLTRIM(Memofield) to extract the
lines. I wanted to retain the CHR(13) but not the CHR(10). Why is the
CHR(10) even there? Doesn't a CHR(13) include a line feed?

Dan

[Bernhard Sander]

Hi Dan,

Post by Dan Musicant
:chr(13) + chr(10)
:alias
:CR + LF
:alias
:h0D h0A exadecimal
:alias
:Carriage Return + Line Feed
:Any ASCII editor put this pair of characters when you insert a CR.
Thanks for the great info. I used ALLTRIM(Memofield) to extract the
lines. I wanted to retain the CHR(13) but not the CHR(10). Why is the
CHR(10) even there? Doesn't a CHR(13) include a line feed?

In addition to what Gianni wrote:
On DOS/Windows, the end of line consists (normally) of CR+LF (h0D0A).
On Unix, they prefer only a LF (h0A), on MAC only a CR (h0D)

In VFP, on some places, you can set a property, to add or not add a LF after CR.
This can be done i.e. in the properties settings of a MODIFY COMMAND window, but
not in the properties settings of a MODIFY MEMO window.
So, I think, you have to use your work around.

You also may have a look at Editbox.AddLineFeeds in help.

Regards

Bernhard Sander

[Dan Musicant]

On Mon, 31 Jan 2011 10:51:27 +0100, Bernhard Sander <***@kein.spam>
wrote:

:Hi Dan,
:
:> :a manually inserted CR consists of:
:> :
:> :chr(13) + chr(10)
:> :alias
:> :CR + LF
:> :alias
:> :h0D h0A exadecimal
:> :alias
:> :Carriage Return + Line Feed
:> :
:> :Any ASCII editor put this pair of characters when you insert a CR.
:
:> Thanks for the great info. I used ALLTRIM(Memofield) to extract the
:> lines. I wanted to retain the CHR(13) but not the CHR(10). Why is the
:> CHR(10) even there? Doesn't a CHR(13) include a line feed?
:
:In addition to what Gianni wrote:
:On DOS/Windows, the end of line consists (normally) of CR+LF (h0D0A).
:On Unix, they prefer only a LF (h0A), on MAC only a CR (h0D)
:
:In VFP, on some places, you can set a property, to add or not add a LF after CR.
:This can be done i.e. in the properties settings of a MODIFY COMMAND window, but
:not in the properties settings of a MODIFY MEMO window.
:So, I think, you have to use your work around.
:
:You also may have a look at Editbox.AddLineFeeds in help.
:
:Regards
:
:Bernhard Sander

Well, my STRTRAN() workaround works well enough and I can easily embed
it in recurring code, forget about it, and things should be fine. The
mystery to me is why the LF is never there when the memo field is
updated by code but is there when I make manual edits (using FoxPro's
editor). My messaging function is custom FoxPro code, actually written
before VFP emerged in the 90's.

Dan


Email: dmusicant at pacbell dot net

[Gianni Turri]

Post by Dan Musicant
Well, my STRTRAN() workaround works well enough and I can easily embed
it in recurring code, forget about it, and things should be fine. The
mystery to me is why the LF is never there when the memo field is
updated by code but is there when I make manual edits (using FoxPro's
editor). My messaging function is custom FoxPro code, actually written
before VFP emerged in the 90's.
Dan
Email: dmusicant at pacbell dot net

Hi Dan,

to answer you I need to view the code used to update the memo field.

[Dan Musicant]

On Tue, 01 Feb 2011 17:46:33 GMT, Gianni Turri
<***@andthisgmail.com> wrote:

:On Tue, 01 Feb 2011 08:45:43 -0800, Dan Musicant <***@privacy.net>
:wrote:
:
:>Well, my STRTRAN() workaround works well enough and I can easily embed
:>it in recurring code, forget about it, and things should be fine. The
:>mystery to me is why the LF is never there when the memo field is
:>updated by code but is there when I make manual edits (using FoxPro's
:>editor). My messaging function is custom FoxPro code, actually written
:>before VFP emerged in the 90's.
:>
:>Dan
:>
:>Email: dmusicant at pacbell dot net
:
:Hi Dan,
:
:to answer you I need to view the code used to update the memo field.

The code is this:

Replace lastwatchm With Dtoc(ldcal)+Chr(13) + Alltrim(lastwatchm)

ldcal is a date type variable, lastwatchm is a memo field that was built
using the same code, looking typically like this:

12/03/2009
11/17/2004
05/11/2004
01/31/2004



Email: dmusicant at pacbell dot net

[Gianni Turri]

Post by Dan Musicant
On Tue, 01 Feb 2011 17:46:33 GMT, Gianni Turri
:>Well, my STRTRAN() workaround works well enough and I can easily embed
:>it in recurring code, forget about it, and things should be fine. The
:>mystery to me is why the LF is never there when the memo field is
:>updated by code but is there when I make manual edits (using FoxPro's
:>editor). My messaging function is custom FoxPro code, actually written
:>before VFP emerged in the 90's.
:>
:>Dan
:>
:>Email: dmusicant at pacbell dot net
:Hi Dan,
:to answer you I need to view the code used to update the memo field.
Replace lastwatchm With Dtoc(ldcal)+Chr(13) + Alltrim(lastwatchm)
ldcal is a date type variable, lastwatchm is a memo field that was built
12/03/2009
11/17/2004
05/11/2004
01/31/2004
Email: dmusicant at pacbell dot net

Hi Dan,

where is the mistery?! :-)

You are adding only chr(13) (that is CR)
so LF (that is chr(10)) never there.

[Dan Musicant]

On Wed, 02 Feb 2011 09:51:36 GMT, Gianni Turri
<***@andthisgmail.com> wrote:

:On Tue, 01 Feb 2011 17:40:57 -0800, Dan Musicant <***@privacy.net>
:wrote:
:
:>On Tue, 01 Feb 2011 17:46:33 GMT, Gianni Turri
:><***@andthisgmail.com> wrote:
:>
:>:On Tue, 01 Feb 2011 08:45:43 -0800, Dan Musicant <***@privacy.net>
:>:wrote:
:>:
:>:>Well, my STRTRAN() workaround works well enough and I can easily embed
:>:>it in recurring code, forget about it, and things should be fine. The
:>:>mystery to me is why the LF is never there when the memo field is
:>:>updated by code but is there when I make manual edits (using FoxPro's
:>:>editor). My messaging function is custom FoxPro code, actually written
:>:>before VFP emerged in the 90's.
:>:>
:>:>Dan
:>:>
:>:>Email: dmusicant at pacbell dot net
:>:
:>:Hi Dan,
:>:
:>:to answer you I need to view the code used to update the memo field.
:>
:>The code is this:
:>
:>Replace lastwatchm With Dtoc(ldcal)+Chr(13) + Alltrim(lastwatchm)
:>
:>ldcal is a date type variable, lastwatchm is a memo field that was built
:>using the same code, looking typically like this:
:>
:>12/03/2009
:>11/17/2004
:>05/11/2004
:>01/31/2004
:>
:>Email: dmusicant at pacbell dot net
:
:Hi Dan,
:
:where is the mistery?! :-)
:
:You are adding only chr(13) (that is CR)
:so LF (that is chr(10)) never there.

But I've been finding that if I enter the Memo field and make any manual
edits, CHR(10) appears at the begining of each line. Somehow the FoxPro
editor decides to insert it. Seems mysterious to me.

Dan


Email: dmusicant at pacbell dot net

[Gene Wirchenko]

On Wed, 02 Feb 2011 09:37:29 -0800, Dan Musicant <***@privacy.net>
wrote:

[snip]

Post by Dan Musicant
But I've been finding that if I enter the Memo field and make any manual
edits, CHR(10) appears at the begining of each line. Somehow the FoxPro
editor decides to insert it. Seems mysterious to me.

The mystery explained: the editor adds it. CRLF-delimited text
lines are standard in files. The editor is likely treating the memo
the same as it would a file.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Tue, 01 Feb 2011 08:45:43 -0800, Dan Musicant <***@privacy.net>
wrote:

[snip]

Post by Dan Musicant
Well, my STRTRAN() workaround works well enough and I can easily embed
it in recurring code, forget about it, and things should be fine. The
mystery to me is why the LF is never there when the memo field is
updated by code but is there when I make manual edits (using FoxPro's
editor). My messaging function is custom FoxPro code, actually written
before VFP emerged in the 90's.

I deal with this in a case where I have to parse memo lines by
using strextract() on the string delimited beginning and end with CR.
This is a redacted version of my code; the full version does more.
HTH.

***** Start of Included Code *****
#define CHRCR chr(13)

lparameters;
thememo && M: the memo to split up

local memocred, memolines, i, oneline

memocred=CHRCR+thememo+CHRCR
memolines=""

for i=1 to occurs(CHRCR,memocred)-1
oneline=strextract(memocred,CHRCR,CHRCR,i)
* Due to how line breaks are handled, they might consist of
CR
* (which is what is expected) or CRLF. In the case of the
latter,
* they have to be stripped so they do not start the text
line.
local nonlf
nonlf=1
do while substr(oneline,nonlf,1)=CHRLF
nonlf=nonlf+1
enddo
oneline=substr(oneline,nonlf)
* ***** Do something with oneline.
endfor
***** End of Included Code *****

Sincerely,

Gene Wirchenko

[Bernhard Sander]

Hi Dan,

Post by Dan Musicant
Well, my STRTRAN() workaround works well enough and I can easily embed
it in recurring code, forget about it, and things should be fine. The
mystery to me is why the LF is never there when the memo field is
updated by code but is there when I make manual edits (using FoxPro's
editor). My messaging function is custom FoxPro code, actually written
before VFP emerged in the 90's.

The answer is quite simple: it's the editbox respectively the MODIFY MEMO
command (which seems to make use of the editbox) that adds the LF before storing
the text to the memo field.

But when you store some string to a memo field by REPLACE memofield WITH string,
exactly that string will be copied to the memo field and no modifications are
made before storing.

This behaviour already could be seen in FP/DOS.
And the mentioned property setting "Save with line feeds" also existed in good
old FP/DOS.

Regards
Bernhard Sander