CHR(10) embedded in Memo fields
Dan Musicant
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
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
Dan Musicant
<removethi...@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
:
Gianni Turri
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
Bernhard Sander
> :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
Dan Musicant
wrote:
:Hi Dan,
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.
Gianni Turri
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.
--
Gianni
Dan Musicant
<removethi...@andthisgmail.com> wrote:
:On Tue, 01 Feb 2011 08:45:43 -0800, Dan Musicant <m...@privacy.net>
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
Gene Wirchenko
wrote:
[snip]
>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
> 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
Gianni Turri
wrote:
>On Tue, 01 Feb 2011 17:46:33 GMT, Gianni Turri
><removethi...@andthisgmail.com> wrote:
>
>:On Tue, 01 Feb 2011 08:45:43 -0800, Dan Musicant <m...@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.
--
Gianni
Dan Musicant
<removethi...@andthisgmail.com> wrote:
:On Tue, 01 Feb 2011 17:40:57 -0800, Dan Musicant <m...@privacy.net>
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.
Gene Wirchenko
wrote:
[snip]
>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