>> 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?
I do. At least if "ANSI" means Windows-125* CPs. This name will mislead me for life. >> 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. You're right, not all HB_TCHAR* stuff can be changed now, nice to see how all these steps lead us to this point. There are still a few HB_TCHAR* usages which could be fixed yet. I'm afraid most of the remaining ones too complicated for me to patch them with confidence. > 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. Yes, code freeze would be about time. I'd like ask everyone to also test hbwin and hbqt, as they have been extensively patches lately and I could see no feedback yet. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
