On Sat, 12 Dec 2009, Szak�ts Viktor wrote: Hi,
> I noticed one part where we miss UNICODE support altogether in > core; when copying to clipboard from GTWVT, GTWIN, it > never makes use of CF_UNICODETEXT. Yes it is but in hb_gt_winapi_setClipboard() CF_UNICODETEXT only enable translation to UNICODE before pasting to clipboard so in fact it does not give any new functionality. It's necessary to change this function to accept unicode strings as parameter. > Plus hb_gt_winapi_setClipboard() > will need the new UNICODE API treatment. See above, both functions should be modified. In hb_gt_winapi_setClipboard() uFormat parameter should inform about type of passed text buffer (declared as 'const void *') not the type to which we should make conversion from 'char *' before pasting data to clipboard so this function should not make any conversions. Similar modification should be done also in hb_gt_winapi_getClipboard() so uFormat will inform about expected type of string we want to retrieve and also hb_gt_winapi_getClipboard() will not make any conversions. Alternatively we can modify above functions to use only one PHB_ITEM pItem parameter so they will make all necessary translations internally. This seems to be the easiest way and in such case in UNICODE builds we can always use CF_UNICODETEXT to avoid possible problems with internal windows translations using different CPs. In non UNICODE builds we can check runtime Windows version and if it's support UNICODE by default then we can use CF_UNICODETEXT otherwise CF_TEXT with hb_setGetOSCP() encoding. I guess that windows users used to set hb_setGetOSCP() to "ANSI" encoding. Am I right? > Probably there will > some more locations which use UNICODE conversion without the > HB_TCHAR macros. Or even with HB_TCHAR_*() macros but in places which needs serious modifications to accept unicode strings without any data lost conversions. I.e. file names in FS API. Now we are using HB_TCHAR_*() functions but replacing them with new API does not help in adding real unicode support and FOPEN() or FCREATE() will still accept correctly only strings using characters from single CP only. Such things needs much deeper modifications which we will have to make adding full UNICODE support to HVM. These are not local modifications which we can safely make now. BTW I still hope we can release final 2.0 before Christmas so I would like to ask everybody to test current code in different environments. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
