Ah yes, Adam. The handler was hard-coded for that particular job. Sorry if it caused a problem.
(Of course, the hard-coding might have been taken even further. If we could be sure that only English month names were to be involved, we could reduce the character set down to “ABCEGLNOPRTUVYyvutrponlgecba”. Then again, we might need to consider extending it to include accented characters for certain languages - but I’d rather not go down that path right now… ;))
To modify the script so that it ignores unlisted characters (spaces, numerical characters, etc.), we could just add a check - perhaps something like the one in this next version. However, I warn you that the results aren’t very pretty, since the case of each character is toggled - making for some decidedly ugly text.
to switchCase(l)
tell "ABCDEFGHIJKLMNOPQRSTUVWXYZzyxwvutsrqponmlkjihgfedcba" to repeat with i in l
set AppleScript's text item delimiters to i
if (count text items) is 2 then set i's contents to item (1 + (count text item 2))
end repeat
set text item delimiters to {""}
l as string
end switchCase
set testString to "This Reverses The Case Of Each Character"
switchCase(testString's characters)
--> "tHIS rEVERSES tHE cASE oF eACH cHARACTER"
For more useful results, a few extra tweaks would be necessary. Rather than iterating through the characters of the text to be converted, this next version turns the algorithm on its head - and runs through the letters of the alphabet instead. This should make it a bit more efficient for converting longer strings, since there should only ever be a maximum of 26 iterations (unless, again, some special/accented characters need to be included for conversion purposes).
to switchCase of t with caps
set n to (caps as integer) * 27
set tid to text item delimiters
tell "ABCDEFGHIJKLMNOPQRSTUVWXYZzyxwvutsrqponmlkjihgfedcba" to ¬
repeat with i from n - 26 to n - 1
set AppleScript's text item delimiters to item -i
set t to t's text items
set AppleScript's text item delimiters to item i
tell t to set t to beginning & ({""} & rest)
end repeat
set text item delimiters to tid
t
end switchCase
set testString to "tHis iS a BiT of a MixeD bAg"
switchCase of testString with caps
--> "THIS IS A BIT OF A MIXED BAG"
switchCase of testString without caps
--> "this is a bit of a mixed bag"
I’m sure this has all been cleared up now (apologies for my absence when all this was going on). Just in case there are any lingering doubts, I had to back-count in my version because the various date/string elements were truncated or manipulated only in the final stage of the operation.
The first half of the statement put together all the date elements…
… while the second half broke them up, moved them around and joined them all up again:
Without the ability to count backwards from the end of the entire string, it would have been necessary to either calculate the length of the month each time - or, as Adam did in his step-by-step version, truncate the month string at an earlier stage - so that all string elements would then be of a known, consistent length each time. (At which point the direction of the count, whether forwards from the beginning, or back from the end, becomes largely a matter of preference.)
There’s another example, above, which takes advantage of this ability to count items from the end of an object. At the start of the (revised) ‘switchCase’ handler, this statement…
… coerces a boolean value (true or false) to an integer (1 or 0) and then multiplies it by 27 (”> 27 or 0). Then, a couple of lines later, this statement appears:
So, if the calling statement specifies with caps, then the variable caps has a boolean value of true - which is coerced to 1… n = 1 * 27 = 27.
In the repeat loop, then, the variable i will increment from a starting value of ( 27 - 26 = ) 1… to a final value of ( 27 - 1 = ) 26. (Straightforward enough.)
When the calling statement passes a without caps parameter, caps = false ”> 0… n = 0 * 27 = 0.
So this time within the loop, i will increment from a starting value of ( 0 - 26 = ) -26… to a final value of ( 0 - 1 = ) -1. (I just found it simpler, from a shared calculation, to derive the range -26 to -1, rather than 27 to 52.)