On Tue, 17 Nov 2009, Szak�ts Viktor wrote:
> I wonder if these can replace HB_TCHAR_* conversion usage.
It can, i.e.:
#ifdef UNICODE
#define HB_PARSTR( n, str, len ) \
hb_parstr_u16( n, HB_CDP_ENDIAN_NATIVE, str, len )
#else
#define HB_PARSTR( n, str, len ) \
hb_parstr( n, hb_setGetOSCP(), str, len )
#endif
[...]
HB_FUNC( WAPI_MESSAGEBOX )
{
LPTSTR lpStr1, lpStr2;
void * hStr1, hStr2;
hStr1 = HB_PARSTR( 2, &lpStr1, NULL );
hStr2 = HB_PARSTR( 3, &lpStr2, NULL );
hb_retni( MessageBox( ( HWND ) hb_parptr( 1 ),
lpStr1, lpStr2, hb_parni( 4 ) ) );
hb_strfree( hStr1 );
hb_strfree( hStr2 );
}
and we should try to migrate to this version because it works well
with simple CP strings and Unicode strings.
Please note that in this code all conversions are done on the fly
and they respect HVM codepage settings so using new API helps also
in code which do not use unicode string items.
> > Please remember that UNICODE does not resolve many problems. In fact using
> > Unicode introduces new very serious problems so for some applications it's
> > not possible to use it and Unicode isn't and will never be working
> > alternative.
> I've yet to write a large Unicode app so it's well possible I'm
> missing some obstacles, however in my case (business app used
> in multiple countries) it would most probably solve much more
> problems than it'd cause. For one thing, I wouldn't have to
> worry again about adding a new CP to the mix. Conversions to
> be done at interface points. Storage of Unicode strings in
> .dbfs seems to be somewhat problematic or at least unusual.
> I'd be glad to read more about such serious possible problems you
> have in mind, and also some cases where it would actually be a
> showstopper as you say.
The 1-st and most important is common sorting algorithm.
If you have three different languages and each of them uses
different national sorting rules then migrating to unicode
you will have to chose some sorting method used for all unicode
strings what means that for at least two languages you will not
be able to replicate exact national sorting conditions. If you
are creating database for phone book and exact national sorting
is a must then you cannot use any language which replaces strict
national sorting with some common for different languages universal
collation algorithm which are used for sorting unicode string and
if support for unicode is not optional then you have to change the
language to some more flexible one which do not force using Unicode.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
