Blocks screenshot selection tool

[janten]

Blocks screenshot selection tool

[janten]

Thank you again for your bug report and insightful comments. I think you are right that simply checking for the presence of the ctrl modifier was not enough. I have built a new version which explicitly checks that only ctrl and a numeric key are pressed. Could you please download the updated Keypad Layout and give it a test? I plan to release this as Keypad Layout 1.6 once I have your feedback on this.

[janten]

Can anyone confirm this? Taking a screenshot with ctrl + cmd + shift + 4 works for me when Keypad Layout 1.5 is running on macOS 10.12.6.

[mariusk]

Oh I should say; I'm on the 10.13 beta.

…

On Aug 10, 2017 18:11, "Jan-Gerd Tenberge" ***@***.***> wrote: Can anyone confirm this? Taking a screenshot with ctrl + cmd + shift + 4 works for me when Keypad Layout 1.5 is running on macOS 10.12.6. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANV9P6Wt1nFoQOqax76Kl5-o8HygKzYks5sWytqgaJpZM4OzCSu> .

[janten]

Can you report this to Apple as a macOS bug and post the Radar ID? I will merge your workaraound if this is not fixed in the final release of 10.13.

[mariusk]

If I understand it I can. You're saying that normally that function would normally not be called with the kCGEventFlagMaskControl if shift is also pressed? My workaround simply just checks if shift is also pressed, and if so skips activating the rest of your placement code. But I really know very little about these APIs, and without further understanding I doubt I'm able to write a good bug report.

[mariusk]

In theory this could also be a bug in your software, where the evaluation order of hooks into keypresses have changed somewhat with 10.13, and that if worked previously by pure chance. But again, I know little about this.

[janten]

Specifically checking for the shift key or even all keys the the program should not react to seems to be an odd requirement. That's why I think we are using the API correctly here. A bug report at Apple would be our best chance to see if the change in 10.13 is intended or accidental. I am no longer a registered developer, so I cannot create the bug report myself.

[mariusk]

I'm not sure I agree. Your hotkeyCallback simply checks if the ctrl key is depressed together with a number key (ctrl-numberkey). If so, you "steal" the event, if not you pass it on to the next application.

So imagine another application doing the same, like the built in cmd-shift-control-numberkey for grabbing stuff from the screen. It checks specifically for all those keys (cmd, shift, control + numberkey), and only grabs the event if everything matches.

If your application ONLY checks for the cmd-numberkey sequence and nothing else, if YOUR application is "in front" of the built in application checking for all the keys, the built in application will never receive any events. Which is pretty much the bug as I've described it.

My workaround is lazy; I just add one additional requirement (that the shift key is not depressed), but in theory I should check for all of them (to avoid stealing somebody else who might have hooked onto cmd-control-numberkey for instance).

If my understanding is correct, the application as is works by chance on older macOS releases, simply because the system checks for cmd-shift-control-numberkey BEFORE the event gets passed to your app. The order might have changed in 10.13, where they run it by user applications BEFORE system applications, and that perfectly explains what is happening.

Which is why I can't report it as a bug until I have some additional information about why this bug isn't in this app itself.

[mariusk]

Seems to work great, good job!