On Tue, 17 Feb 2009, Miguel Angel Marchuet wrote:
Hi,
>>> hb_strDescend don't respect HB_SetCodePage
>> Yes it doesn't and it's expected behavior.
> Then is a Clipper bug, that can be solved, for example adding a new parameter
> ?
It cannot be touched because DESCEND() is commonly used function and
should return binary compatible data with other dbase compatible systems
if you want to share some data, f.e. indexes.
But of course you can create new function which will respect current
active HVM CP though for some languages which uses accented characters
with the same direct wight it's mathematically impossible to create such
function for all 256 binary characters keeping the original string length
so the results will be well sorted with active CP. The result will have
to be longer because you have to store some additional information with
character wights.
For CPs which does not have such condition you can create simple conversion
table indexed by character ASCII value. The final conversion function should
give revertible results so:
str == my_descend( my_descend( str ) )
you can use the above rule to test if you made everything well.
F.e. use this code:
for i := 0 to 255
if ! chr( i ) == my_descend( my_descend( chr( i ) ) )
? "ERROR at:", i
endif
next
I'm leaving writing my_descend() function which will work for any active
HVM CP using above conditions for you as homework ;-). It should not
take more then 20 short lines for dynamically create translation table
and translate given string using this table. For final version you can
use one static translation table or many different in hash table indexed
by active CP.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
