|
|
 |
 |
 |
 |
 |
 |
 |
Working
with UNICODE in Visual Basic 6.0
By
Siddharth Barman OverviewThough the server based products like Windows NT and Windows 2000 offer full support for UNICODE, Win9X range of operating systems have failed to show even minimum support for this new standard. This however does not mean that if you develop applications that target the Windows NT / 2000 operating systems, the application will be fully compatible with UNICODE. This is specially true for applications that have been developed using Visual Basic. This exercise has been carried out to determine the problem areas that one would probably encounter when developing an International application using Visual Basic 6. For applications that are being built from scratch, the problem would be of a lesser magnitude. However, if we want to have internationalization features in an existing application, a lot of revamping will be required to the existing code. User Interface The first step one must take in order to work with UNICODE is never to use Visual Basic’s intrinsic controls. Instead, use the Form 2.0 controls. This approach also may have its own problems. The application may be using certain third party controls for which there is no equivalent UNCODE version. This would pose a big problem to the development team. It is always safer to use the Forms 2.0 controls for standard user interface. If you do require any third party controls, make sure they support UNICODE. Database Interaction Most Visual Basic applications communicate with backend products like SQL Server using ActiveX Data Objects (ADO). ADO fully supports UNICODE because COM itself fully supports UNICODE. It always advisable to make use of Ado’s support for inserting, modifying & selecting capabilities to store and retrieve data and from backend databases. If existing code is written in a way that makes use of raw SQL statements, make sure all UNICODE texts are prefixed with a N. e.g. insert into student values(N’Siddharth’, N’Barman’) Another important point to note would be, UNICODE strings cannot be stored in a standard Char or VarChar database column. You should always declare a nChar or an nVarChar column. SQL Server has an nChar / nVarChar type. Other database systems would support UNICODE, however using a different type name. Controls texts and captions Even after using Forms 2.0 controls, it is difficult to work with UNICODE text at the code level. Therefore it is recommended, that all language versions of all controls and displayable text should be stored in a database of a UNCODE text file from where the displayable can be picked up and the user interface captions / text can be set. Have a database approach also allows flexible additions of new languages to the application. .NET, the solution? .NET languages like VB.NET, C# and VC++.NET have full support for UNICODE. If possible, it is always recommended to upgrade to the new versions of the respective language.
|
