vbCrLf (VBA/all)

Topic

New Reply

Good evening all
When controlling the view of text in an InputBox or MsgBox, I have been in the habit of using Chr(13) where vbCrLf appears to be equivalent. I seek your advice on the advantages and or cautions on using one versus the other.

Reply | Quote

Replies

vbCrLf is not equivalent to Chr(13). The equivalent of Chr(13) is vbCr. VbCrLf is the equivalent of Chr(13) + Chr(10).

Reply | Quote

Thank you Charlotte

Reply | Quote

As Charlotte says, the two are not equivalent, although they may end up having an equivalent effect.
The Cr part is a Carriage return – Chr(13) and the Lf part is a Linefeed – Chr(10).
For the sorts of controls you’re speaking of, they have the same effect on the output, but some programs (Notepad for instance) won’t begin a new line unless there is a carriage return and linefeed. If there is only one or the other it displays the character missing box as a character. This is also a “gotcha” for text files formatted as ASCII vs. Unix.

IMO, it’s always better to use one of the built-in VB constants because you get the bonuses of intellisense come implicit error checking if you use “Option Explicit”… and, of course, you do use “Option Explicit”… don’t you Don!
These are some of the common ones:

vbCrLf = “n” # Carriage returnlinefeed combination
vbCr = chr(13) # Carriage return character
vbLf = chr(10) # Linefeed character
vbNewLine = “n” # Platform-specific new line character; whichever is appropriate for current platform
vbNullChar = chr(0) # Character having value 0
vbNullString = chr(0) # String having value 0 Not the same as a zero-length string (“”); used for calling external procedures
vbTab = chr(9) # Tab character
vbBack = chr(8) # Backspace character
vbFormFeed = chr(12) # Not useful in Microsoft Windows
vbVerticalTab = chr(11) # Not useful in Microsoft Windows

You’ll find a more comprehensive list here.

Alan

Reply | Quote

Thanks for the input Alan. That was exactly the type of info I was looking for.
btw: Of course I use Option Explicit. AFTER I was bitten for the umpteenth time.

Reply | Quote

I think that’s the way we all learned it, Don. We’re as bad as teenagers – won’t listen, but finally resign after getting sick & tired of being beaten black & blue. I’m surprised at myself on that one, having been weened on C/C++, where you have to declare absolutely everything.

Glad the info helped too.

Alan

Reply | Quote

Alan,

Just a quibble on one of the entries in this helpful list:

vbNullString = chr(0) # String having value 0 Not the same as a zero-length string (“”); used for calling external procedures

– not sure that that is accurate.

From way back I’ve used vbNullString in place of a a zero-length string. Here’s a snippet from VB & VBA In a Nutshell, by Paul Lomax:

[indent]

---

vbNullString
Assigns or tests for a zero-length (empty) string. For example, the statement:
strVar1 = vbNullString
is equivalent to:
strVar1 = “”

---

[/indent]
The following code will return a blank message box, not one with “0” in it:

   Dim str As String
   str = vbNullString
   MsgBox str

Gary

Reply | Quote

The sentence[indent]

---

Not the same as a zero-length string (“”); used for calling external procedures

---

[/indent] is straight from the VBA help file – which is wrong here! You are correct that vbNullString is exactly the same as “”. I think that sentence was intended for vbNullChar, a string containing Chr(0); this is used where Windows API functions expect C-style (zero-terminated) strings.

Reply | Quote

I must say that I skipped over that, but agree with you that it is incorrect. I thought the author might be confusing “Null is not the same as Empty” with “vbNullString is not the same as an empty string”.

However, I think there may be a subtle difference that the author didn’t realize (since he/she appears to have lifted it straight from the VBA help file, as Hans points out). Do correct me if I’m wrong on this, because it may be an inappropriate hangover from C/C++. An empty string “” is an actual string, of the string data type, and therefore carries the minimum overhead of any other string – some handful of bytes. But vbNullString is just a zero, denoting the equivalent of a NULL in C. Although the results of using either are the same at the end of the day, the length of the day might vary since vbNullString would be faster to process.

Alan

Edited – I think I’m right on this, as detailed in Faster Visual Basic Programs:

“A loop assigning an empty string to a string variable 10 million times gives surprising results, too. While absolute times may again differ on your system, the improvement when using vbNullString is significant:

e$ = “” 1.51 s
e$ = vbNullString 0.38 s

Note that the predefined constant vbNullString is not exactly the same as an emtpy string, but it can be used as an equivalent and even returns true when comparing vbNullString = “” (while vbNullString is a null pointer, “” results in a pointer to a string with zero length; however, not all API/DLL functions handle them identically, so be careful).

Checking if a string is empty 10 million times can also be done in different ways. Here are the times for doing it 10 million times on our test system:

If “ABC” = “” 0.73 s
If “ABC” = vbNullString 0.57 s
If Len(“ABC”) = 0 0.46 s
If LenB(“ABC”) = 0 0.39 s

So the speed nearly doubles if you are using LenB instead of comparing the string with an empty string. Note that you should not replace Len by LenB in general, since LenB returns the byte position in the VB double-byte strings instead of the character position. But for simply checking if the length is zero, LenB is the fastest method.”

Reply | Quote

Alan,

Thanks for the link – an interesting read, and some good tips there.

The explanation of vbNullString gibes with what I’d read in the past (originally in an article by Ken Getz on ways to optimize VBA code – couldn’t find the original article, but a version that’s part of an article on optimizing Access applications can be found in the MSDN library
here). Don’t know if the increased speed matters anymore, but I prefer vbNullString to “” in my code simply because it stands out more clearly when I read it!

Gary

Reply | Quote

Hi Gary

It’s an interesting but subtle point… but as you say, will the speed difference be significant at the end of the day? I too lean towards using the built-in constant names for other good reasons. I’ve also still got the “#define” C preprocessor monkey on my back (a good thing probably) that pushes me towards this kind of usage.

Alan

Just to add something concrete to the argument, the following code:

Public Sub testStrings()

    Dim strEmpty As String
    Dim strNull As String
    
    strEmpty = ""
    strNull = vbNullString
    
    Debug.Print LenB(strEmpty)
    Debug.Print StrPtr(strEmpty)
    Debug.Print LenB(strNull)
    Debug.Print StrPtr(strNull)

End Sub

will output:
0
5032560
0
0

Clearly, the two cases are different. First up, it appears that a “string” variable in VB is actually a (2-byte) pointer to a character array, similar to but not the same as those used in C. The fact that the pointer to strNull is zero would indicate that the variable strNull has not actually been initialized. By contrast, the pointer to strEmpty is not Null, so memory has been allocated to strEmpty.

Even though LenB(strEmpty) is zero, I think that this is a result of how the character array is stored, as well as how LenB() reports. It’s now my understanding that a VB string “abc” (not the pointer, but the actual contents) has the following structure:

length of array in bytes: 00 00 00 06 (4-byte value = 6, excluding NULL terminator)
unicode character array: 00 61 00 62 00 63 (6 bytes of unicode)
NULL terminator: 00 00

I believe that strEmpty would therefore be stored as:
00 00 00 00
(nothing here)
00 00

which is a total of 6 bytes of “nothingness”. The LenB() function appears to report the 4-byte length value i.e. the number of bytes after the first 4-byte length value, up to but not including the (2-byte Unicode) NULL terminator – so it returns zero for a “” empty string. But the 6-byte overhead is always there. Apparently, depending on what’s using the string, the unicode character array can contain other null characters not intended as terminators, so the 4-byte length value precedes the character array proper, in addition to the NULL terminator. I don’t understand the mechanics of this aspect myself.

Reply | Quote