At 3:32 AM -0500 11/24/03, Peter Gatti wrote:
I did some more experimenting and found that a file I had saved
using Len() read back just fine using lenB(). I see what you mean,
but the two behave as if they're interchangeable.
They're really not.
Just the same, I will file the bug.
Thank you.
Ah, but of course that's not really the case; there are only 127
ASCII numbers and they don't include any of what you're calling
"option characters."
After reading this comment, I decided to find out what the ASC
number is for (option g) or the character ©
That character has no ASCII code; it's not in the ASCII set.
so I wrote a little program to display it using
me.text=str(Asc("©")) in an edit field's open event. It's 169.
That's the result returned by the Asc() function, yes, but it's not
its ASCII code. Using RB 5.0 or later, what you've got there would
be Unicode code point for that character.
(Off-topic side note: the Character Palette in Mac OS 10.3 no longer
seems to show the Unicode code point! Augh! I relied on that
feature! Oh well...)
So I expanded the code to:
for x= 0 to 169
s=chr(x)+chr(13)
You're using Chr() out of its valid range here. Chr() is only
defined for parameter values 0 through 127 (i.e., the ASCII range).
Beyond that it will give you an answer, for the sake of backwards
compatibility, but exactly what it gives you is undefined and you
should not be using it.
me.text=me.text + str(x)+" "+s
next
RB just stalled and quit.
That's interesting; it shouldn't do that. I wonder if the EditField
choked on the Chr(0)? Hmm...
So I limited the loop to x= 164 to 169 and this is the result.
164 ¬¨¬®¬¨¬Æ¬¨¬®¬¨?ÜÄö?Ñ??àöÄ àöàÇÄö? ??¬¨à´
...i.e., garbage. That's what you get for using Chr() outside its
defined range. :)
Joe, the copyright symbol © is commonly used and IMO it's a real
limitation if RB can't handle these key combination characters which
have ASC numbers above 127.
But of course it CAN handle them. RB's support for the text
encodings of the world is the best of any development environment
I've ever seen. Just follow these guidelines:
1. Stop thinking that anything outside the range of 0-127 is ASCII. It's not.
2. Stop thinking that all the world is MacRoman (which is the
extension of ASCII that you're used to). The vast majority of the
world is not.
3. Don't call Chr() with a value outside the range 0 to 127.
4. If you need a character outside the ASCII range, simply get it
from the character set you have in mind. For example, you should be
using Encodings.UTF8.Chr(169) to get Unicode code point 169,
represented in UTF-8. If you want some MacRoman character, use
Encodings.MacRoman.Chr(x). And so on.
5. Don't use Len when you really mean LenB, or vice versa. Always
think about whether you mean characters or bytes.
6. Similar for Mid/MidB, Left/LeftB, etc.
It didn't work because now I understand Encoding is not the problem.
Yes, it is.
It's RB not being able to deal with ASC characters above 127.
That is not the case.
Cheers,
- Joe
--
,------------------------------------------------------------------.
| Joseph J. Strout REAL Software, Inc. |
| joe at realsoftware dot com http://www.realsoftware.com |
`------------------------------------------------------------------'
- - -
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|