On 04/04/14 22:02, Fraser Gordon wrote:
<snip>
That note was really just to encourage people to look elsewhere in case
they stumble across the entry when searching for "uppercase" or similar.
Trying to uppercase a string using codepointProperty is likely to be
significantly slower than using the built-in functions. For persons like
yourself, however, feel free to ignore the warning - I think it is fair
to say that your use is not "general purpose".
"numToChar" produced ASCII chars.
Does this mean that "numToChar" has gone west?
NumToChar only returns ASCII characters (by interpreting the number
given as modulo 256 - backwards compatibility strikes again). For
Unicode codepoints, you should instead use numToCodepoint.
That 's going to put the kibosh if I ever decide to up date my
commercial version from 4.5.
My "Devawriter Pro", "PISMO" and up-coming "Grendel" all depend on
scripts like this:
on rawKeyDown ROARK
if ROARK = 42 then
set the useUnicode to true
set the unicodeText of the selectedText to numToChar(4567)
select after the selextedText
else
pass rawKeyDown
end if
end rawKeyDown
in the light of what you have just written I would have to change every
"numToChar" statement
to "numToCodepoint" . . . another reason why . . . err, never mind.
This needs to be adequately documented as quite an important change.
It is worth noting that codepointProperty only accepts single
codepoints, i.e you shouldn't put quotation marks or similar around the
codepoint. Basically, the expression passed to the function should
either be the output of numToCodepoint or an expression of the form
"codepoint x of ..." - as you saw, it will get snooty if you pass a
string to it (though a string of length 1, which is what a codepoint is
really, also works).
Regards,
Fraser
Best, Richmond.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
