Hi Przemek,
? WA1->FIELD1 >= WA2->FIELD2
WA1 uses CP1, WA2 uses CP2
Please define RDD CP in this case?
In this case there is no RDD CP context involved in my
understanding, this is executed in the caller CP context.
And what if it's FOR or WHILE clause of some RDD commands
like INDEX ON ..., COUNT or SET FILTER?
I'd think INDEX ON expression is definitely RDD CP
context, just like FOR/WHILE and every other code
initiated by the RDD.
[ Honestly until you see or agree that my raised issue is
a valid one, I see no point in speculating on implementation
details. A possible answer could be that the issue is there,
but implementation is far-reaching or not possible because
of certain legacy constructs, or else, but first I think
we should identify the problem. Maybe my thinking is
completely wrong from start. ]
[ BTW the other problem is conversion from one CP to
another from .prg code. But that's really another topic. ]
Another more sophisticated solution could be that first
WA1->FIELD1 is converted to caller CP from WA1 CP, then
WA2->FIELD2 is also converted to caller CP from WA2 CP,
and then comparison is made using the caller CP context.
How do you want to find such information in more complicated
expressions
like:
WA1->(UDF1()) >= WA2->(UDF2())
FUNC UDF1
return WA1->FIELD1+WA2->FIELD2
FUNC UDF2
...
???
I think the WA CP to caller CP conversion should be
done when evaluating the content of FIELDn. From this
point the context is of the caller's.
Another view of this is if we'd say that HVM is internally
Unicode, and we need to convert everything coming from outside
to it, and use a selected national collation when doing
these comparisons.
Back to prev mail for sec, can shade some light specifically
this issue:
Why can we do this now:
---
hb_setcodepage( "CP_ZZ" )
dbUseArea( ..., "CP_XX" )
dbUseArea( ..., "CP_XX" )
---
But not this:
---
hb_setcodepage( "CP_ZZ" )
hb_rdddefaultcodepage( "CP_XX" )
dbUseArea( ... )
dbUseArea( ... )
---
hb_rdddefaultcodepage( "CP_XX" )
Will enable translations for all open WAs even if user does not need
any
No, it should enable translations for _newly opened_ WAs.
(in the current thread possibly).
All it does is giving a default to the already existing
<codepage> parameter.
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.
I still don't understand why isn't it a problem to support
<codepage> currently as a parameter. Can we say it's a broken
feature?
[ my battery going flat in a minute. See you later ]
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
