Carraige Return Character

Business Central/NAV Developers Forum
1

Hi,

How can i remove the carraige return character from the text string?

2

I was a programmer 15 years ago, and my suggestion might not be applicable to Navision [;)] - but “Carriage Return” is char(13)…

As string length functions usually doesn’t include CR, you might trim string to its length, but it works only if CR is the LAST one in string, but not if somewhere in the middle…

3

…and remember that CHAR(10) which is LF often follows CR.

If you import into NAV and use TEXTMODE(TRUE) CR/LF is removed automatically; same when using a dataport. Using binary import you have to handle this yourself.

4

I have to export data from navision. The data includes description of item which has CR/LF characters. When ever the CR/LF characters are encountered, the line breaks. I wish, if there is any staright solution in Navision to resolve this.

5

Faisal,

Hmm… Data exported from Navision shouldn’t contain any CR/LFs…

If you say Descr field is the cause, it makes me think, that your system somebody has modified.

Standart Descr is text(50) now (was text(30) in earlier versions). In many situations it’s not enough, and if someone, not being aware of all serious consequences, simply extends the standart field to maximum 250 chars, instead of adding CUSTOM field for LongDescr purposes, many problems arise.

So, check first for mods there and how the CR/LFs happened to appear in Navision data.

6

Hi Modris

This is the standard text field where users are actually copying and pasting data from excel. I think this is how carraige return characters are getting in to the description field.

Any how i have written the follwing function to remove the characters from the end:

RemoveCarraigeReturnFromString(TextString : Text[50];VAR ProcessedString : Text[50])
StringLength:=STRLEN(TextString);
AlphabetString:=‘abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ ,/1234567890’;
FOR I := StringLength DOWNTO 1 DO BEGIN
SingleText := COPYSTR(TextString, I,1);
CharFound:=FALSE;
FOR J:=1 TO 52 DO BEGIN
IF SingleText=COPYSTR(AlphabetString, J,1) THEN BEGIN
CharFound:=TRUE;
END;
IF CharFound=TRUE THEN J:=52;
END;
IF CharFound=FALSE THEN BEGIN
ProcessedString:= DELSTR(TextString, I,1);
END;
IF CharFound=TRUE THEN I:=1;
END;

7

If you do Ctr-C Ctrl-V from Excel, you really get this CR/LF - they appear as two squares in the end of pasted data, be it string, numeric or date.

But I had never had a problem with this - just hit Backspace twice, and they’re gone! For numeric fields Navision even doesn’t allow to leave the field, reporting input error… And no customer has ever asked to remove them…

added: BTW where do you suppose to put this function? As I wrote, with numerics & dates Navision will raise its own err message…

8

Hi Modris,

I am working with Navision since more than 12 years and have found the problem with the CR/LF carracters in alle versions (NAV2013 not yet tested). My company has just migrated to NAV2009 and I am really disppointed that this bug has not yet been fixed.

The 2 characters ar invisible - both in NAV and in Excel. So why should a user hit Backspace, if he/she isn’t aware that there are any characters to be deleted?

9

Hi Andrea,

Would you tell someone who should be using your company diesel car that it uses diesel and not gasoline? As I see it then this is really the same. It’s very annoying that training sometimes is required, and maybe some day the machines (cars and computers) will be able to think for us. [;)] But that day is not here yet. [:)]

In terms of copying data from Excel into NAV, then this as never really been “supported”. Most of the times it works, other times it does. Same when you export data from NAV to XML files. If you data (like your customer name) holds characters such as < or > then the XML files will not work after the export, as these are so-called control characters. Just as the Excel CR/LF characters are when they are exported. NAV uses a different charset from Excel, thus it will require that the control characters are first converted.

So in terms of Microsoft and NAV, then this is not really a bug. But I do agree that this is surely an inconvenience.

And when that has been said, then I still see this error in NAV 2009 Classic, but not in NAV 2009 RoleTailored nor in NAV 2013.

10

Correct, the problem is only with the classic clients. However, it can easily be resolved with small changes in Codeunit 1

Look for the MakeText-Function in CU1 and add the following line directly at the beginning:

// — Changes

Text := RemoveBadChars(Text);

// +++ Changes

Add a new function to CU1:

PROCEDURE RemoveBadChars@1000000001(t@1000000000 : Text[250]) : Text[250];
VAR
Ch@1000000001 : Text[3];
BEGIN
Ch[1] := 9; // TAB
Ch[2] := 10; // LF
Ch[3] := 13; // CR
EXIT(DELCHR(t, ‘=’, Ch));
END;

This function will remove CR, LF and TAB characters. All done.

Of course, this function only works with “new” applied data to the database. But you also can call this function from your code.

Still one issue here. This is to remove the “bad characters” from the TEXT-type field. But how we do it for CODE-type fields as a function MakeCode does not exists in Codeunit 1? Easy way as usual with NAV. Add a new function to CU1:

PROCEDURE MakeCode@109(VAR CodeText@1000000000 : Text[250]) : Integer;
BEGIN
CodeText := RemoveBadChars(CodeText);
EXIT(0);
END;

Give this function the ID 109 (!) and the client will call it for the CODE-type fields.

Rgrds

Walter