Curious behavior using Chr(10) & Chr(13)

[VicM]

Hi,
I'm using Access 2010 on both a Win 7 Pro box and a Win 11 Pro box.
My database prints address labels on Avery type 5167/8167 (1/2" x 1&3/4").
There are 3 lines for the address and all 3 lines can grow or shrink.

The first line prints the name; the second line prints the street address, and the third line prints the city, state & zip code.

When I have two lines for the street address, for instance an apartment number or other required information for delivery, I want the second address line to print as 2 lines.

The code for the second address line is as follows:

=Trim([Address Line 1]) & Chr(13) & Chr(10) & Trim([Address Line 2])

This works as intended, for example:

255 Main St.​

Apt 7B​

However, when I first started coding this, I coded as follows:

=Trim([Address Line 1]) & Chr(10) & Chr(13) & Trim([Address Line 2])

This did not work as intended and gave me the following:

255 Main St.Apt7B​

After reading some posts containing the Chr(13) and Chr(10) codes, I also tried the following:

=Trim([Address Line 1]) & vbCrLf & Trim([Address Line 2])

But after entering it as above, when looking at it again it showed as follows:

=Trim([Address Line 1]) & [vbCrLf] & Trim([Address Line 2])

Which when executed, popped a window asking for vbCrLf.

I find it curious that the order of the Chr codes matters.

Does anyone have an explanation?

Thanks,
Vic

 

[SkipVought]

Vic,

ASCII 13 is a Carriage Return, while ASCII 10 is a Line Feed.

In the first case either the platen or the print head returns on the same line to the left hand print position.

In the second case the platen advances one line.

You could, on some older printers, over-print a line by simply entering ASCII 13, or you could print a diagonal as below, by simply entering ASCII 10 with no Line Feed, after each character..
[pre]
A
B
C
[/pre]
There must be a reason that the order matters when entering both. Of that I am unaware.

Skip,
[sub]
Just traded in my OLD subtlety...
for a NUance![/sub]
"The most incomprehensible thing about the universe is that it is comprehensible" A. Einstein

You Matter...
unless you multiply yourself by the speed of light squared, then...
You Energy!

 

[combo]

Access does not understand vbCrLf. If you don't like Chr(13) & Chr(10), you can consider creation of function that returns vbCrLf (as string) and use it instead.

combo

 

[VicM]

SkipVought & combo

Thanks for replying.

I understand the difference between the Chr codes. And I'm using a laser printer.

I don't have a problem using the Chr codes.

I just thought is was weird that the order of the Chr codes mattered.

Vic

 

[SoftwareRT]

Unix/Linux Convention (LF):
In Unix and Linux systems, the convention for representing a newline is to use chr(10) (LF) alone, without chr(13) (CR). Therefore, in these systems, lines are terminated with LF character only.

Windows Convention (CRLF):
In Windows systems, the convention for representing a newline is to use both chr(13) (CR) followed by chr(10) (LF). Therefore, lines in Windows text files are terminated with CR followed by LF (CRLF).

Old Macintosh Convention (CR):
In older Macintosh systems (prior to Mac OS X), the convention for representing a newline is to use chr(13) (CR) alone, without chr(10) (LF). Therefore, lines in these systems are terminated with CR character only.