Kbase P122599: COPY-LOB removes Carriage return CR character.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/22/2010 |
|
Status: Verified
SYMPTOM(s):
COPY-LOB removes Carriage return CR character.
COPY-LOB copying a LONGCHAR field displayed in a LARGE editor to a file, removes the Carriage return character CHR(13) 0D from the end of each line.
After COPY-LOB, each line should finish with line feed carriage return 0D0A, but with COPY-LOB it simply finishes 0A.
For example, if assigning a large editor value to a longcharacter variable:
elongchar = hLargedit:INPUT-VALUE.
COPY-LOB elongchar TO FILE("readme.txt").
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.1B
CAUSE:
Bug# OE00147307
CAUSE:
This change in behavior came about when we upgraded to a newer version of the RichEdit control several years ago. The new version of RichEdit counts CR and LF separately, while the older version counted the combination as one character.
We stripped out the carriage returns so that editor methods which use character indexes (such as SUBSTRING) worked properly without requiring ABL code changes in existing applications. Unfortunately, this means that in most cases if you put text into a large editor the carriage returns will be lost.
The status of this is: No Plans To Fix. The current behavior has existed for more than five years from when this was first reported, and going back to the original behavior would just expose a different set of applications to problems. Addressing the problem with workarounds on a case-by-case basis is the best approach at this point.
FIX:
To work around this use the SAVE-FILE method instead. For example:
hLargedit:SAVE-FILE("readme.txt").