Hi Przemek, Unfortunately this i to İ (LATIN CAPITAL LETTER I WITH DOT ABOVE - 0x98 <152> in CP857) upper conversion generates more problems, now in MEMOEDIT:
Error BASE/1004 Message not found: HBMEMOED˜TOR:HBEDITOR Called from __ERRRT_SBASE(0) Called from HBMEMOED˜TOR:ERROR(0) Called from (b)HBOBJECT(0) Called from HBMEMOED˜TOR:MSGNOTFOUND(0) Called from HBMEMOED˜TOR:HBEDITOR(0) Called from HBMEMOED˜TOR:EDIT(0) Called from MEMOEDIT(0) The missed I in 'HBMEMOED˜TOR' is this İ ugly character. I don't know how to handle this. Thank you in advance, István -----Original Message----- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak Sent: 2009. október 6. 18:59 To: Harbour Project Main Developer List. Subject: Re: [Harbour] UPPER error iwith some CP-s On Tue, 06 Oct 2009, Bisz István wrote: Hi, > I found a quite strange behavior in some CP settings necessary in my > project. > See the following sample: > CODE > proc main() > set alternate to uperr.txt additive > set alternate on > REQUEST HB_CODEPAGE_TR857 > HB_SETCODEPAGE( "TR857" ) > ? "diag=diag", UPPER("diag=diag") > ? "diag", UPPER("diag") > return > ENDCODE > generating the wrong output: > diag=diag D˜AG=D˜AG > diag DIAG It's Clipper compatible behavior in UPPER() optimization. Clipper optimize UPPER( <cConst> ) at compile time if <cConst> contains only characters like [A-Za-z0-9 ] and as result if gives <cUpperConst> where characters like [a-z] are converted to [A-Z]. During compilation CP is unknown so only such strings are translated and only pure Latin letters. In Harbour Clipper behavior is fully replicated because some code which initialize static variables needs it, i.e.: static s := upper( "diag" ) Unfortunately it creates problems for Turkish CPs where upper("i") is not "I" but due to compile time optimization it's wrongly translated to "I". In your example first string contains "=" character what disables compile time UPPER() optimization so it's correctly translated at runtime but the second string is fully optimized. The only one solution I can give you is not using UPPER() with string constant values containing Turkish strings. Maybe in the future I'll add new -k? switch to disable UPPER() optimization but I cannot make it in default builds due to compatibility with existing code. If it's critical for you now then you can disable UPPER() optimization in Harbour compiler code and recompile your custom Harbour version. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
