|
|
Locale-Sensitive Visual Basic Methods and PropertiesI18n OverviewAlthough Visual Basic employs UTF-16 Unicode (technically UCS-2) as its base technology for strings, it often converts these Unicode Strings to what Microsoft calls "ANSI" form and back again. This can cause problems and corruption of data since the conversion process uses the system code page (CP_ACP). In the case of a backend that serves many clients in many locales, the system code page often is not the correct code page for the client being served. In addition, VB uses the system locale settings for Date and Time formatting, which is also incorrect in a server environment where the client is not on the host machine. A summary of the areas that need to be specifically analyzed in a VB application are:
I18n Support for Dates and TimesIn an internationalized application, code that contains formatting strings such as "mm/dd/yyyy" should be refactored if the dates are to be displayed to an end user. For example, whereas May 03, 2005 in the U.S. would be displayed as 05/03/2005, in Spain it would be displayed as 03/05/2005 ("dd/mm/yyyy"). Unfortunately, the locale-sensitive formatting methods that VB provides, are solely dependent on the system locale. As an example, VB's FormatDateTime method always formats according to the system locale. This is inadequate when using VB in a server component, and unfortunately there is no method in VB that will take an argument to specify to use a locale other than the system locale for formatting. Another problem with the FormatDateTime method is that it always uses the system timezone setting when formatting dates and times. This is incorrect in a server setting as the dates and times will be wrong if a user/client is in a different timezone. Problematic Methods - System Setting DependentThe following methods behave differently based on Locale, and have the appearance of being locale-aware, but unfortunately only work based on the System's Locale setting:
Problematic Methods - Hidden ConversionsThe following methods are intended to be Independent of Regional Locale settings. However, care must be taken in parameter usage, since they will accept Variants as well as Dates for parameters. If the Variant happens to be a String, the System Regional Locale is used to convert the String to a Date. This effectively ruins their "independent" nature and can lead to quite unexpected results:
The SolutionTo solve these formatting problems, all the problematic locale-sensitive Date and Time methods listed above will need to be completely avoided and replaced with calls to a new layer which accepts a locale and is capable of properly formatting Dates and Times. This can either be an in-house COM object that uses native WinAPI calls, or a third-party package such as ICU. We recommend the ICU package, as there is a significant amount of logic that needs to be written around the native WinAPI calls to properly interface between VB and these calls to handle both locale and timezone information. For more information on Visual Basic functions, see Microsoft's Visual Basic 6.0.
Win32 API calls from Visual Basic
The Microsoft Win32 API can be accessed from Visual Basic by using the In a similar vein, although VB Strings are natively implemented in UTF-16, Microsoft made the decision for backwards compatibility reasons with Windows 98 and earlier to always convert Strings in VB Declare statements to ANSI, a conversion it does for you "under the covers". Unfortunately, it always uses the system code page (CP_ACP) for this conversion, which, in a server environment, is often the incorrect code page. Therefore, in order to "trick" VB into not thinking that a value is string (and thus avoiding the unwanted ANSI conversion), use the native UTF-16 "W" interfaces.
As an example, note that the Private Declare Function RegQueryValueEx Lib "advapi32" Alias "RegQueryValueExA" (ByVal hKey As Long, ByVal lpValueName As String, ByVal lpReserved As Long, ByRef lpType As Long, ByVal szData As String, ByRef lpcbData As Long) As Long
In order to avoid the potentially corrupting effects of the String
conversion, use the "W" Unicode UTF-16 call directly ( Private Declare Function RegQueryValueEx Lib "advapi32" Alias "RegQueryValueExW" (ByVal hKey As Long, ByVal lpValueName As Long, ByVal lpReserved As Long, ByRef lpType As Long, ByVal szData As Long, ByRef lpcbData As Long) As Long Note that even with correct calling of a Win32 function to avoid data corruption, you must still ensure that the function is being used properly to support the current locale of the application. For information on the locale-dependent Windows functions, see Locale-Sensitive Windows C++ Functions. Locale-Sensitive Visual Basic Method ListClick on a specific method below to get more information (usually from Microsoft's Visual Basic website). In some cases, where the method is supported via Microsoft's Win32 API, the link leads to Globalyzer's C++ Help, which can be used to determine internationalization solutions in your Visual Basic application.
Locale-Sensitive Visual Basic Properties ListClick on a specific property below to get more information (usually from Microsoft's Visual Basic website). In some cases, where the property or constant is supported via Microsoft's Win32 API, the link leads to Globalyzer's C++ Help, which can be used to determine internationalization solutions in your Visual Basic application. Win32 Locale FunctionsFor internationalization information and guidelines, click here.
Otherwise, click on a specific function for more information. Note that the help for these
functions are part of the C++ Help, but the internationalization issues they discuss are applicable
to a Visual Basic program calling into the Win32 API via the Locale-Sensitive Win32 FunctionsFor internationalization information and guidelines, click here.
Otherwise, click on a specific function for more information. Note that the help for these
functions are part of the C++ Help, but the internationalization issues they discuss are applicable to a Visual Basic program calling into the Win32 API via the Locale-Sensitive Win32 Character Set NamesFor internationalization information and guidelines, click here.
Note that the help for these
functions are part of the C++ Help, but the internationalization issues they discuss are applicable to a Visual Basic program calling into the Win32 API via the
|
Locale-Sensitive Methods Table of Contents