cAPITAL lETTER pROBLEM

[dunbarx]

Richmond.

Just do what all Americans think and do.

Expect that everyone should learn idiomatic English. We refuse to learn any other language.

Craig

[bogs]

Bogs.
LC cannot do what you imply in your handler. You cannot even determine the case of, say, the first char of the name of a control, since the caseSensitive property does not hold in that arena.

You must find another reference to work with. Richmond needs to rename his images.

Is the dictionary correct that custom props can be judged by case? If I read it correctly, then that would be a reference that would work instead of the variable I used.

I assumed (sad, I know) that for some reason case would apply to text in a variable, but even though the variable has the right text in it, I guess case sensitivity does not work there (in a variable)?

[richmond62]

insensitivity has been normal

Hmm.

Expect that everyone should learn idiomatic English.

Well, that be fine by me, but I bain't sure that those Americans talk English; mayholp they
talk American.

AND, if one wants to be really bitchy I have always wondered why
the LiveCode people are unable to spell things such as COLOUR in English. Edinburgh, last time I looked, was in Scotland, not just off the coast of Rhode Island.

When I was over in the American territories for my son's graduation I picked up this:
-

dic.jpeg (7.03 KiB) Viewed 5407 times

-
have been working my way through Webster's fascinating introduction ever since: lovely book.

[dunbarx]

Bogs wrote:

Is the dictionary correct that custom props can be judged by case? If I read it correctly, then that would be a reference that would work instead of the variable I used.

How would that work? For example, one cannot have two custom properties in the same control such as:
"A" and "a".

LC will not accept both, since it believes that if one already has "A", then one cannot also have "a". It believes these are one and the same. For custom props, LC is case-blind

Craig

[jacque]

On the teaching front, especially as I teach kids who, on a day to day basis, use
a non-Latin alphabet, explaining to them that LiveCode
is unable to differentiate between images called "abc" and "ABC",
but CAN differentiate between images called "щюя" and "ЩЮЯ" is a bit of a headache.

That made me wonder. The example uses unicode where every letter has a different code. The first 128 chars of the unicode tables are ascii which are treated differently in LC, possibly to retain backward compatibility. I wonder if you'd get the results you want by specifying the button names as unicode text. Don't ask me how, I've never had to worry about it.

[richmond62]

[richmond62]

I wonder if you'd get the results you want by specifying the button names as unicode text.

That is certainly a thought; however that won't affect teaching kids who find it hard to understand why a capital letter in the Bulgarian alphabet is treated differently to its lower case equivalent while that does not hod true with the Latin ("English") alphabet.

[Klaus]

notGood.png

A is a reserved word -> if there is A file...

[richmond62]

[Klaus]

notGood2.png

Oh, sorry, my fault, took a while.
Wrong syntax, you cannot PUT something into a custom property, this has to be SET!

Code: Select all

...
set the x of img "fishy" to "Cheese"
...

So this will also work with -> the A of img "fishy"

Nevertheless is A a reserved word

[richmond62]

Wrong syntax

Ouch.

[bogs]

Bogs wrote:
. Is the dictionary correct that custom props can be judged by case? If I read it correctly, then that would be a reference that would work instead of the variable I used.

. How would that work? For example, one cannot have two custom properties in the same control such as:
"A" and "a".
. LC will not accept both, since it believes that if one already has "A", then one cannot also have "a". It believes these are one and the same. For custom props, LC is case-blind

That isn't what the dictionary says -

The caseSensitive also affects custom property names and array key names. If the caseSensitive is true, custom property names that differ only in the case of their letters are treated as different custom properties. If the caseSensitive is false, custom property names that differ only in letter case cannot be distinguished from each other. The same is true for the keys of array elements.

Apparently, you can have for instance cpropa and cpropA, and they would be completely different as long as caseSensitive is set to true. Again, unless I am completely missing some key distinction. According to the above, you could also do it by array key name, although using a cp seems a bit more direct.

And I still am curious as to the variable not reporting as a string, which case sensitive should work with.

[dunbarx]

Hmmm.

Have to check this out. I simply tried to set two custom props from the inspector in a button, "A", and "a". After setting "A", I was prevented from creating "a" at all. The property inspector made the second process disappear.

I did not try to do it under script control. Hmmm....

Craig

[dunbarx]

Nope.

Tried it from script. LC will WILL permit "X" and "x" to live in the same control, but they cannot seem to have different values.

Code: Select all

on mouseUp
   set the caseSensitive to "true"
   
   set the "X" of btn 1 to "upper"
   set the "x" of btn 1 to "lower"
end mouseUp

Both properties now exist, but both have the value "upper".

Maybe because it came first?

Craig

[bogs]

I'll look into it tomorrow if I find the time. Either that, or maybe Panos will stop by to elucidate this for us