Difference between revisions of "LMD VCL - Unicode Support"

Revision as of 15:55, 10 November 2007

General unicode support notes:

• Use WideString instead of String (if library has ansi version, the use defines (see TLMDString type))
• One symbol, in general case, isn't equal one byte - it's very important
• Use Unicode API function instead of its Ansi version. These function has W suffix. As example DrawTextW, ExtTextOutW etc.
• For any operation on unicode string use routines from LMDStrings.pas (must be in core modules)
• For unicode string lists use classes from LMDUnicodeStrings
• Win 9x/Me has very poor unicode support and need to check all controls on these OSes.

Detailed notes (units contains in LMDRTL package)

LMDUnicode Unit contains Unicode related low level implementation. All implementation is made in terms of WideString and WideChar standard Delphi types. Services provided by this unit assumed to be not depended of LMD_UNICODE compiler switch, because they can be used in some special situations, for example for working with Unicode enabled external COM objects, like script engines, ect.

LMDUnicodeStrings Unit defines TLMDWideStrings and TLMDWideStringList classes. As in previous unit this types assumed to be independed of LMD_UNICODE compiler switch. However, in .Net Vcl versions TLMDWideStrings and TLMDWideStringList are declared as aliases to Delphi standard TStrings and TStringList classes, since there classes already Unicode enabled in .Net. The later fact does not affect primary notion of TLMDWideStrings and TLMDWideStringList classes – they are still Unicode enabled string lists.

LMDTypes Unit finally declares string and character types that must be used consistently in controls development and other routines, based on our Unicode support strategy. Only Unicode implementation itself and special cases are assumed to use WideString type directly. Following types are defined: TLMDString, TLMDChar, PLMDChar, TLMDStrings and TLMDStringList. There types are depends of LMD_UNICODE compiler switch.

LMDStrings Unit contain many string utilities. Almost every function is duplicated three times: LMDAnsiXXX version – uses standard Delphi string type. Please note, that this is actually a version that always consistent with any Vcl version. It actually Unicode for Unicode Vcl (in .Net). LMDWideXXX version – always uses WideString type. Unicode in any Vcl version. LMDXXX version – uses our TLMDString type. The behavior depends of LMD_UNICODE compiler switch. Just like our string types, this version of utilities should be used consistently in controls development. Specialized versions are provided for old non-Unicode controls and special cases. Also two proxy string-list types are defined: TLMDStringsProxy – is an adapter that adapts TLMDStrings object to TStrings interface. TLMDAnsiStringsProxy – is an adapter that adapts TStrings object to TLMDStrings interface.

LMDUnicodeControl Unit provide utilities for implementing Unicode enabled GUI controls in Vcl. All utilities in this unit are declared in terms of our string types. The behavior of utilities depends of LMD_UNICODE compiler switch. Just like for our string types, the utilities are designed to be used unconditionally in controls development. The primary goal is to hide LMD_UNICODE compiler switch and Vcl version differences.

LMDUnicodeCtrls Unit provides subset of unicode enabled standard controls with LMDUnicodeControl unit help. It can be used in Windows NT family OSes to show and manipulate unicode data.

LMDUnicodeDialogs Unit contains 2 classes - TLMDOpenDilaog and TLMDSaveDialog, that supports unicode features of Windows NT family OSes. They can be used to open/save files with unicode names, can be customized by unicode strings (unicode Title, Filters etc.). Also they used by TLMDFileOpenDialog/TLMDFileSaveDialog (since LMD Tools 2007.1) as Windows XP replacement of Windows Vista new dialog.

Discussing Unicode controls we must denote two different tasks: Unicode enabled control interface; Implementation of the control that allow it to work with Unicode properly.