The Problem (Q-score 9, ranked #23rd of 95 in the VBA Core archive)
The scenario as originally posted in 2016
I was converting a VBA macro to C#. And in VBA chr(7) can simply be concatenated to a string as if chr() would yield a string. Why can’t this be done in C#?
I am trying to find a clear answer to my question. I have read many posts and related questions on this on SO and several other sites. For example this one which is the key answer (many others are marked off as dulpicates and redirect to this one): What's the equivalent of VB's Asc() and Chr() functions in C#?
And unfortunately the answer is not clear and many times they state that this is a correct use:
string mystring=(char)7;
Yet it gives me a compiler error as it does not evaluate as a string.
I had to use this to make it work:
string mystring=((char)7).ToString();
This would be the equivalent of the VB Chr() function, really as Chr() in VB evaluates as a string.
My question is this: do I always need to cast the char over to string explicitly or there are some cases where it converts over implicitly?
UPDATE:
Per @Dirk’s answer, this also works:
string mystring = "" + (char)7;
This does not lessen my mystery. If concatenation works why there is no implicit cast??
I would like to get a full explanation on the difference between the VB Chr() and its equivalents in C#. I would appreciate any reference where I can read up on, or even examples would do. Thanks in advance.
Why community consensus is tight on this one
Across 95 VBA Core entries in the archive, the accepted answer here holds strong answer (top 25 %%) status — meaning voters are unusually aligned on the right fix.
The Verified Solution — strong answer (top 25 %%) (+21)
Advisory answer — community consensus with reference links
Note: the verified answer below is a reference / advisory response rather than a copy-ready snippet.
You are opening Pandora’s box with this question. Chr() is a legacy function in VB.NET, any modern code should be using ChrW() instead. The difference is the way the character value should be interpreted, ChrW() assumes the character code is Unicode (W = wide). Chr() rolls back the clock to the previous century, a stone age without Unicode where characters were either in the ASCII character set (0..127) or an “extended” character (128..255). Where the extended characters belong to a code page. Many, many different code pages were in common use. A very significant disaster, programs could not properly interpret text that was generated by another machine located in a different country. Or even in the same country, Japan had multiple code pages in common use with none of them dominant. Producing mojibake.
I’ll assume you mean ChrW(), nobody likes mojibake. Not C# either. Using Char.ToString() is fine, the alternative is to use the string constructor that takes a char:
string mystring = new string((char)7, 1);
Or the more general form you might prefer:
public static string ChrW(int code) {
return new string((char)code, 1);
}
Not the only way to do it, using literals is possible as well and likely to be what you prefer over a helper method. And the basic reason that C# does not need a helper function like Chr(). ASCII control code 7 is the bell character, it BEEPs you when you write it to the console, you can use an escape for that:
string mystring = "a";
Not exactly memorable, this comes from Unix. Other ones are “b” for backspace, “t” for a tab, “r” for a carriage return and “n” for a line feed. A classic trick to erase the last typed character in a console window is Console.Write("b b");. The Environment.NewLine property should be noted. Which is about as far as you should push it with control characters.
And last but not least the U and u specifier that lets you encode any character:
string mystring = "u0007";
Not obvious from the example but the u value needs to be hexadecimal. U is needed when you use codepoints from the upper Unicode bit planes.
When to Use It — classic (2013–2016)
Ranked #23rd in its category — specialized fit
This pattern sits in the 83% tail relative to the top answer. Reach for it when your scenario closely matches the question title; otherwise browse the VBA Core archive for a higher-consensus alternative.
What changed between 2016 and 2026
The answer is 10 years old. The VBA Core object model has been stable across Office 2013, 2016, 2019, 2021, 365, and 2024/2026 LTSC, so the pattern still compiles. Changes that might affect you: 64-bit API declarations (use PtrSafe), blocked macros in downloaded files (Mark-of-the-Web), and the shift toward Office Scripts for web-first workflows.