Chris Hill wrote:
> NO, the issue is that native VB6 only uses API interfaces
> that are limited to ANSI.
Chris,
That's not true. I've built a dozen or so commercial programs in VB6 that
read/write/manipulate Unicode data, including reading and writing UTF-8 files,
presenting data entry screens, running reports, etc. A few are still being
used. Perhaps there are old third-party components that are not Unicode-aware,
but VB6 was certainly not limited to ANSI, API or otherwise. VB^ used in MS
Access? I have only done some light scripting there so I don't know what issue
Unicode may have presented there.
The string type in VB6 used "wide" characters (as they were called then),
16-bits each. It's true that one had to be careful when calling Windows APIs
directly and call the correct "W" methods. Calling Windows APIs directly was
probably less than 15% of the code in my applications. To write a UTF-8 file,
one had to use the "binary" version of the Open File statement ("Open FileSpec
For Binary Access Write …") and then convert the chars to UTF-8 before using
the PUT call to write the text, but any reasonably-accomplished VB6 programmer
knew how to do that. The details escape me, but using binary I/O may only have
been necessary when low-level control was required, such as reading/writing the
Byte-Order-Mark (BOM).
Of course, VB6 was very easy to use and so there were a lot of junior-level
programmers who may have been flummoxed by working with Unicode, but that's not
the fault of VB6.
John
--
LegacyUserGroup mailing list
[email protected]
To manage your subscription and unsubscribe
http://legacyusers.com/mailman/listinfo/legacyusergroup_legacyusers.com
Archives at:
http://www.mail-archive.com/[email protected]/
