On Wed, 18 Nov 2009, Szak�ts Viktor wrote: > 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.
Exactly. > 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. In the above you are saying that you do not need native unicode support because all what you need is some method to store characters for many different languages. For this we for sure do not need unicode in core code. Just simply use everywhere UTF8 and add new GT driver which will operate on UTF8. HVM does not have to know anything about it. Such method is already used by some GUI libraries for [x]Harbour. > 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. I do not find Unicode in Java and C# as good solution. In general string management in these languages is one of the most important reasons for me to not use them. Now string management in Harbour is hundreds or even thousands times faster then in above languages when a lot of strings have to be allocated, i.e. when report is created and I would like to keep this performance. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
