Hi, For the people who don't know it already, how Unicode is handled in MSEgui for FPC 2.4:
- All GUI relevant string parameters and variables and all DB-Field strings are of type msestring, all characters are of type msechar. - MSEgui has a set of file handling routines with parameters of type filenamety. - For FPC 2.4 msestring = UnicodeString, msechar = UnicodeChar, filenamety = msestring. - The MSEgui sources don't contain characters > #127 and therefore can be stored in any codepage and compiled with any -Fcxxx or even without -Fcxxx. Non ASCII string constants are defined in #xxxx format. - User source normally is stored in utf-8 and compiled with -Fcutf8 -> user source can contain any string constant and is portable between platforms. - Conversion between msestring and the system encoding and vice versa is handled transparently by the FPC widestringmanager. So exchange msestring with system routines is easy. - Database strings are converted to/from msestrings while fetching/sending the data. The MSEgui DB-access components have an option to either use the system encoding by the assistance of widestringmanager or using utf-8. - INI-textfiles are stored in utf-8 and therfore portable. The user benefits: - There is only one encoding in MSEgui framework, it is the same on all platforms. - In the majority of cases the fast and convenient character access by index can be used. This is important for beginners. - The current FPC UnicodeString is fast, simple, has little overhead and is well tested. So please don't destroy this ideal solution by dropping current FPC UnicodeString in favour of the Delphi string which is complicated, less performant, will have many new bugs and is inscrutable by the average user! Please remember how many time it took to fix WideString. I don't want to go this ordeal again. Martin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
