When I use TYPE A KEYSTROKE action to type a lowercase letter into an application, it's always sent in lowercase even if CAPS LOCK is turned on.
I can guess that the KM Engine doesn't check for the status of the CAPS LOCK flag, or the SHIFT keys, when it sends out its key, but why shouldn't it? Why couldn't it? And more importantly, what makes the most sense? If both options could make some sense to some people, then couldn't the TYPE action support both methods?
Upon reflection, I'm guessing that most people would probably want the TYPE action to disregard whatever the user wants via the CAPS LOCK key. But I have a legitimate need and I wish it would at least have an option to respect the CAPS LOCK state.
Regretfully, your suggestion does not help. All that modifier does is tell you whether the CAPS LOCK key is currently physically depressed. It does absolutely nothing to tell me if the CAPS LOCK green light is on. Nobody uses CAPS LOCK as a SHIFT key, they use it only for its ability to change a flag in macOS, and the state of the flag can be seen in the little green light that appears on the CAPS LOCK key. As a result I could not use that code to "check the status of the CAPS LOCK flag" which was the requirement that I stated in my original question.
The modifier condition in KM does not tell you the state of macOS's internal CAPS LOCK state, it tells you only whether the CAPS LOCK key is currently being pressed down, which for my purposes is useless.
I searched the internet again to see if there was a way to find out the state with a macOS command. And this time I found one. However it requires that xQuartz be installed. For some reason I can't recall, I have that installed. The command is "xset -q". The first time I ran that command it took about 15 seconds to return a value. Subsequent calls took between 0.1 and 0.5 seconds each. So it's a bit slow, but it works.
To reiterate, the KM modifier condition tests only the current state of depression of the CAPS LOCK key, which does not solve my problem. If I'm depressing the key when the green light is off, it returns true. If I'm pressing the key when the green light is on, it returns true. And if the CAPS LOCK key is not depressed it returns false irrespective of the state of the green light. My programs require knowledge of the green light so KM will not help me at all.
My results are equal to yours. But I absolutely guarantee you my test results were different when I did this test a number of months ago. I probably spent about 8 hours testing this and absolutely could not get it to work the way it's working now. It was working the way I carefully described it in my paragraph that starts with "To reiterate,".
I wonder if KM has changed? So I searched the release notes. I found mention of a change to the modifiers condition but I couldn't understand what the change meant:
Fixed the non-edit display of the Modifiers condition.
It doesn't say that it changed the display of the CAPS LOCK test, but as I said I assure you when I tested this before, I got different results.
But since it works now, I won't bother testing my assertions by finding an older copy of KM and testing that. I know what I know, and I don't care to prove myself right about a historical issue.
Hmm, I think may have written about this problem on this forum back when the problem existed. But I don't care, it's all water under the bridge now.
The number of times that's happened to me are too numerous to count. And it's so frustrating when that happens, because you just can't be sure what's different.
But since it works now, I won't bother testing my assertions by finding an older copy of KM and testing that. I know what I know, and I don't care to prove myself right about a historical issue.
You don't have to prove it to me. I believe you 100%.
I see your points, but my philosophy is that the user should have control over KM, not the other way around. KM isn't the user. The user is the user, and is the ultimate authority. And what I find odd is that KM doesn't even give the user a chance to override here. There isn't even a flag on the action to let the user have control. Oh well, I figured I would lose this argument. Chalk it up to my high ratio of rejected suggestions. In this case the user is the loser.
I presume you did a little more testing and deleted your post after further consideration!
