Why doesn't the TYPE action respect the state of the CAPS LOCK button?

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.

Personally, I'm glad it doesn't respect caps lock. I want complete control over what it does.

If you want to take caps lock into account, you can use this:

Hope that helps. :smile:


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.

I saw your post before you deleted it. :slight_smile: I presume you did a little more testing and deleted your post after further consideration!

This works on my machine.

Yeah, I worded the prompt poorly. I posted a better example.

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%.

In any case, I'm glad it works now. :smile:

Exactly! If you want to type something with a specific case, then use Insert Text by Typing action, and enter the text with the desired case.

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.

Sure. And if you send mixed case, it sends mixed case and you don't have to press the shift key periodically.

The simulated text does not have anything to do with the physical keyboard.

1 Like

Thanks goodness for that. Else it would be a total mess, with macro behavior being very unpredictable.