chrw error 5

[Elroy]

IDK, but this whole discussion seems a bit silly to me, and possibly confusing to a great many. Therefore, I’ll outline my understanding of it all.

Character Coding Schemes:

ASCII: A 7-bit scheme which encodes all the letters found on a USA keyboard, along with several teletype control characters. This was originally developed for teletype machines. It actually uses 8-bits (one-byte) per character, but the high-bit is always zero (or, if we go way back, possibly a check-sum).

ANSI: An 8-bit scheme, along with a Locale ID code, that encodes a great many characters. It’s a perfect super-set of ASCII, with the Locale ID specifying the meaning of the second 128 (high-bit-on) characters. With Windows, this Locale ID is typically set within the OS and not the actual character string.

UTF-8: A one-to-four byte scheme. It is very different from ANSI. But it is a perfect super-set of ASCII. Presently, this is by far the most prevalent character encoding scheme used, and is used by virtually all of HTTP communications. There is no Locale ID associated with UTF-8, as each character has its own unique code.

UCS-2: A two-byte (only/always) scheme. It is not an exact super-set of ASCII, and is also different from ANSI. However, ASCII can rather easily be encoded into UCS-2 by simply inserting a zero for the high-byte of each ASCII character, with the low-byte staying the same (high-bit off, as ASCII is 7-bit). As with UTF-8, there is no Locale ID, as each character has its own unique code.

UTF-16: A two-byte or four-byte scheme. This one is an exact super-set of UCS-2 (with a small argument for a possible exception). The original UCS-2 stated that 65536 (FFFF) characters would be allowed. However, this didn’t leave a code for specifying a four-byte character. Therefore, the UCS-2 standard was modified with codes between D800 and DFFF being marked as “reserved”. More specifically, these were reserved to denote four-byte UTF-16 encoding (if UTF-16 was being used).

------

Now, a couple more notes. When stored to files, there may be a BOM (Byte Order Mark) consideration. This can help us determine the type of encoding in the file. Furthermore, under certain circumstances, there may be little-endian vs big-endian byte order considerations. However, I’m considering these things beyond the scope of this discussion.

------

Also, it’s important to note that, without Microsoft, none of us would probably have ever heard of either UCS-2 or UTF-16, as the vast majority of the rest of the world uses UTF-8. However, we have heard of Microsoft.

Microsoft OSs start out as ASCII, then ANSI, and then progressed to UCS-2, finally progressing all the way to UTF-16. And, as of somewhat late, they also have API calls for accommodating (translating to/from) UTF-8.

VB6 came along within the Microsoft culture as ANSI was in full swing, and UCS-2 was beginning to take hold, and it got caught between the two. Virtually all of the string properties of the intrinsic controls only work with ANSI (including the Properties Window). However, almost all of the VB6 functions and statements expect VB6’s BSTR string variables to be UCS-2. When a string is assigned to one of the control’s string properties, it is converted from UCS-2 to ANSI (using the computer’s Locale ID), and then displayed.

------

Just to be clear on VB6’s functions and statements (involved with strings), here’s the list, along with their capabilities:

InStr - Understands only UCS-2.
InStrRev - Understands only UCS-2.
Mid statement - Understands only UCS-2.
Mid function - Understands only UCS-2.
Len - Reports a count assuming UCS-2 characters.
Left - Understands only UCS-2.
Right - Understands only UCS-2.
LCase - Understands only UCS-2.
UCase - Understands only UCS-2.
Space - Creates a string of UCS-2 (or UTF-16, same thing) spaces.
String - Understands only UCS-2.
Chr - Understands only ANSI range, but returns a UCS-2 character.
Asc - Understands only ANSI, reads low byte of UCS-2 character.
ChrW - Understands only UCS-2.
AscW - Understands only UCS-2.

Ok, some that will incidentally work with either UCS-2 or UTF-16, but only because UTF-16 is a super-set of UCS-2, and spaces are the same thing:

Trim
LTrim
RTrim

And then, the StrConv function:

StrConv – Except when used with either the vbUnicode or vbFromUnicode constants, this only understands UCS-2. And, when used with the vbUnicode or vbFromUnicode constants, it gives you a way to internally convert a BSTR string from ANSI to UCS-2 (or vice-versa), with nothing to do with UTF-16. Also, as a note, a string that’s converted to ANSI will not work correctly with the above functions.

------

The StrPtr function and API calls - A full discussion of these is beyond the scope of this post. However, it does remind us that string memory can just be treated as “assigned memory” with no explicit meaning (and I've never denied this). Yes, sure, we can stuff a UTF-8 string, or an ANSI string (hinted above with StrConv), or any other type of encoded character string into our string’s memory if we so choose. However, again, beware that VB6’s functions will not understand this type of encoded string.

But, when we do this, and possibly use this string memory as a simple buffer, we can do all kinds of things with our strings (via StrPtr and API calls).

------

To me, the rest of it is mostly semantics and hubris. And to help me remember how VB6’s functions and statements work, I think of VB6 strings as UCS-2 encoded. If others wish to think of strings simply as assigned memory, holding whatever they designate, that’s fine too.

And yes, if we’re willing to build replacement functions and statements for all the VB6 string functions and statements (along with the likely assistance of some API calls), we could certainly expand VB6 so that it could fully deal with UTF-16 strings (or even UTF-8 strings, for that matter).

------

So LeandroA, that’s the long answer as to why ChrW didn’t work for you.