Hi Przemek,
What about situations when part of expression is taken
from your source code and other part from table?
INDEX ON FOR MY_FIELD <= "[text with national character]"
If you begin to implement it and resolve all problems which will
appear then you will end with CDP pointer attached to each string
item (HB_IT_STRING) what in some cases may not be bed idea but you
will also have to define the behavior of + and - operations for
strings
with two different encoding. Probably by simple using encoding of 1-st
nonempty string. Next it will be necessary to define the behavior of
<, <=, >, >=, =, ==, $ operators for strings with different encoding
and implement it in HVM. Without attaching CDP information to string
item you will not be able to realize above idea because when string
item is created the evaluation context may not be known yet.
So as long as we will not have such functionality we have to use
simplified
version which translate all strings to one encoding used by
application.
Yes, that's exactly what you say, the CP context
is not even process dependent, but string dependent.
This is the right solution. It's not a quick and easy
feature though unfortunately.
And here could come the advantage of being internally Unicode,
since in this case the CP doesn't need to be added next to
each string. And this is probably we should rather do, instead
of introducing CP information for each string. And just catch
the I/O points where such CP information is needed to know
how to interpret non-Unicode strings.
No it's not different topic because you can have in one expression
string items created from .prg source code and string items created
from table. If you have
INDEX ON ... FOR MY_FIELD1=="<string with national character>"
then MY_FIELD1 have to be created with the same encoding as item
created
by "<string with national character>" or during '==' evaluation you
will
have to make translation dynamically. To make it dynamically you
will have
to attach to each string item information about CDP or use some
arbitrary
CDP used for all comparisons.
Unfortunately this is currently not easily or generically
possible, by using explicit functions calls that is.
[ There was a problem report quite a while ago which targeted
this problem, and the solution was to sync a few collations
to make it suitable for such conversion. There is a lot to do
here overall. ]
I can also update all existing code and add CODEPAGE clause to USE
and
related commands/functions:
use table new codepage hb_setcodepage()
copy to table2 codepage hb_setcodepage()
What is exactly the same what you have do in new code when you want
to enable automatic translations.
There different is only that your proposition breaks backward
compatibility because existing Clipper code will have to be updated.
translation and want to open table in raw form, f.e. to extract
binary
so it will break existing code. The old problems will still exists
and we
will have new one. User will have to add to existing code saving and
restoring hb_rdddefaultcodepage() to make it structural safe.
No existing code will be broken, as this is a new command,
and no defaults would be changed.
See above. It will be yet another _SET_EXACT switch :-(
Okay I now see your concern.
Anyhow the RDD codepage support seems also quite broken then,
and the final word is that currently Harbour doesn't really
support CPs, besides one per app selected for the RDDs plus
all the app string functions (comparison, UPPER()/LOWER()),
and there is a grade of support to convert strings to another
CP for GT output. Period.
This - even now - could cause all sort of problems, if a
3rd party lib tries to fiddle with hb_setcodepage().
[ my battery going flat in a minute. See you later ]
:-)
Back on A/C power now :)
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
