My usual insensitivity

[richmond62]

"Over the road" someone posted this:

I'm wondering how to match 2 variables with case sensitivity. For example, AlPhA123 will currently match Alpha123. How do I match these variables with Case Sensitivity?

I think that what the OP meant in the third sentence was really How do I filter these variables with Case Sensitivity?

i.e. that a comparison between AlPhA123 and Alpha123 will show up as a MISMATCH.

It was then pointed out:

Important: Messages, object names, and LiveCode terms are never treated as case-sensitive,
even if the caseSensitive is set to true.

Which basically means that however those variables are compared they will always come up as a match.

An answer is to put the 2 variables into fields and then compare the field contents:
-

Screenshot 2025-01-31 at 11.28.15.png (105.15 KiB) Viewed 364 times

-
For some funny reason, over there, it is felt to be "bad form" to put data into fields.

[FourthWorld]

For some funny reason, over there, it is felt to be "bad form" to put data into fields.

Fields are for displaying text. Rendering text requires many thousands of executable instructions.

If a given operation doesn't require display, the additional overhead of using a field instead of just keeping the variable contents in a variable will reduce throughput efficiency. Depending on the operation, this can easily total up beyond an order of magnitude more CPU time, potentially slowing the user experience and, in laptops, draining battery power.

[richmond62]

If a given operation doesn't require display, the additional overhead of using a field instead of just keeping the variable contents in a variable will reduce throughput efficiency. Depending on the operation, this can easily total up beyond an order of magnitude more CPU time, potentially slowing the user experience and, in laptops, draining battery power.

That makes sense in the context of real-life situations: it does NOT make sense in terms of good pedagogy.

Good pedagogy requires that as many things are SEEN as possible: and by putting variables (which, as they are abstract, are diffcult for learners to grasp) into fields they become visible.

Once a learner has worked out HOW to manipulate data they can see, it is relatively easy to move from visible fields to invisible variables: and far, far easier and smoother for the learner than "hitting them over the head" with abstractions on day 1.

AND for a very long time LC was blathering on and on about LC as a teaching tool . . .

AND as they did precious little of any obvious value in that direction, the Forums might not be a bad place to start learning: especially if the topics under discussion avoid abstraction as far as is possible.

[tperry2x]

If you wanted to see this in a field, that's fine - particularly if you wanted coloured output. Otherwise, it could all be in a variable.

If you wanted to know what the differences are, if it was a match, if a character was completely different - I've done a modified example too:

case-compare.png (37.8 KiB) Viewed 346 times

Case-Sensitivity.oxtstack

(8.13 KiB) Downloaded 10 times

It works by convering each char to a number, and comparing. All wrapped in a function, so you just pass two strings to it. See script of button "compare". The real work is done in the card script, but takes milliseconds.