After all, there is UTF-7, UTF-8, UTF-16 (Big and Little Endian versions), UTF-32 (Big and Little Endian versions) and UCS-2 (UTF-16 is basically the same from what I've read over the past couple of days, though UTF-16 allows for the characters outside of the BMP)... .NET and FB both deal with Little Endian only (though with .NET it is more of a preference rather than a requirement), so perhaps that is an option for QB64 should Unicode be implemented. Regarding the idea of having a single ASC function, that is implemented in FB via the combination of the -lang switch and preprocessor definitions resulting from that switch. If Galleon were to create a function acting similar to ASC for Unicode, there are two options that I can think of at the moment: 1) Use two functions, where ASC is for the QB dialect and _ASC or _ASC64 or something like that would support both ASCII and Unicode 2) Use a single function, and add something like the -lang switch. As for CHRW$, it is a good idea if Unicode is implemented. I believe Galleon has stated that extensions to the QB language are added by prepending underscores to the names, like _INTEGER64 for example, to avoid clashing with QB variable names, procedures, and so on in existing QB programs. ------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. |
