One of the big changes in software, and especially in the move up from VB 6 to VB.NET, is the ability to build globalization into your code! In a recent article about resource files in Visual Basic, I wrote, "Microsoft has heard clearly heard the jingling clink of Rupees, Euros, Yen, and Kroner in .NET." Resource files are one way that you can make your code available to people speaking different languages, but theres a lot more to it than that. In this article, I'm going to show you the code you need to use to make your program output match a different "culture".
First, what do I mean by culture?
There is a whole list of things that need to be changed in your program to make it acceptable to other cultures. They include ...
- language differences such as different fonts and right-to-left instead of left-to-right writing styles
- different calendars
- format patterns for dates, currency, and numbers
- the sort order for strings
All of these can be customized using dozens of different objects in the System.Globalization namespace.
Another key technology for globalization is the Unicode standard. This standard was originally created by a worldwide industry group and has now been recognized by the World Wide Web Consortium (W3C). VB.NET is fully Unicode compliant. The key advantage of Unicode is that you can display virtually all characters in all languages. Currently Unicode 3.2 provides 95,000 characters but the standard allows more than 1.1 million code points, so there's room for expansion. The Unicode mapping that you will see most often is called UTF-16 where 16 bits are normally used for each character (but it's also possible to map pairs of 16-bit values to a character). UTF-16 "little-endian" is the encoding standard at Microsoft. Windows 3.1 supported Unicode and it's the required encoding since Windows NT. (The "little-endian" description means that the least significant byte is placed in the initial position.)
All Win32 APIs that take a text argument have both a generic function prototype and two definitions: An "A" version for eight bit characters and a "W" version for 16 bit or "wide" characters. For example, using the SetWindowText API,
Private Declare Function SetWindowText _
Lib "user32" _
Alias "SetWindowTextA" (ByVal hwnd As Long, _
ByVal lpString As String) As Long
or
Private Declare Function SetWindowText _
Lib "user32" _
Alias "SetWindowTextW" (ByVal hwnd As Long, _
ByVal lpString As String) As Long
... or leave out the "Alias" entirely since the Win32 API defaults to the "W" version. Note that this will create an error on Windows 95 and earlier versions.
Migrating code from Win16 to full Win32 Unicode can be difficult and time consuming, depending on the original code. Full globalization also requires a lot of Windows specific configuration - for example, the selection of "code pages". This could be yet another reason for completely rewriting VB 6 and earlier applications in VB.NET rather than attempting a direct conversion. If you want more (much more), I recommend Win32 API Programming with Visual Basic, by Steven Roman (ISBN 1-56592-631-5).
