Hi Przemek,
> #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.
So if I understand correctly, it will do both the UNICODE
conversion and any required OSCP conversion. So f.e. WAPI_SHELLEXECUTE()
code, which is currently quite on the ugly side, can be highly
simplified. For other WAPI functions where OSCP conversion
isn't explicitly implemented ATM, above modification will
automatically enable it, like in your above WAPI_MESSAGEBOX()
example.
> 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.
Unicode sorting is indeed an interesting thing. But to me this
seems rather a high level app logic problem than a disadvantage
of Unicode. After all Unicode just makes it possible to store
different languages next to each other, and in this case sorting
opens a whole new problem, but even with Unicode encoded strings,
one can opt to use a certain, language specific collation and
put other chars f.e. to the end of list. On the database level
this may be helped by per table (or per index) collation selection.
All in all if native Unicode is good for Java and C#, I believe
it must be good for Harbour, too. Of course we may need to solve
some extra Clipper/.dbf-specific problems along the way.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
