I have a cross platform Qt application that's running into some trouble in OSX. There's a feature that OSX has that I didn't even know existed - the 'Help' key. My MBP doesn't have one, and neither does my Apple wired keyboard purchased a year ago. It seems that this is mostly something that older Macs have. Apparently it generates the same scan code as the Insert key on PC keyboards.
Anyways, when the Help key is pressed, the cursor over our application (or any application that receives the Help key event) turns into a little question mark. This seems to be part of what's called 'context-sensitive help mode', as documented in the NSHelpManager's setContextHelpModeActive: method and in the NSApplication's activateContextHelpMode: method docs. From the docs:
In this mode, the cursor becomes a question mark, and help appears for any user interface item the user clicks.
Most applications don’t use this method. Instead, applications enter
context-sensitive mode when the user presses the Help key.
Applications exit context-sensitive help mode upon the first event
after a help window is displayed.
How many Cocoa developers actually know about this? I'm assuming that clicking on something in the application with this question mark cursor should do something like bring up a help message, but I haven't found a single Cocoa application where it actually does anything at all - not even Apple's apps do anything. In fact, it even seems to put a lot of applications into a strange mode where the cursor text selection is enabled.
The problem is that when we change the application cursor programmatically in Qt when we're in this help-question-cursor-mode, bad things happen. Specifically, our application actually crashes. The crash happens deep inside Cocoa in the NSApplication's NSHelpManager. I'd like to find out why we're seeing this crash, but I'm actually more interested in how we can suppress this 'help' mode. There's nothing in Qt or Cocoa that I can see that would stop it, other than perhaps intercepting and squashing an event, which I haven't tried yet.
Does anyone know any more about this?
Related
Is there any way to replace a special character with a keyboard shortcut live?
For instance: Writing $ would actually press ctrl+n or arrow key left
Every help is much appreciated!
This is primarily speculation with a little experience and research mixed in.
This sort of thing is easy enough if you are checking in an application that currently has focus, but creating a universal keypress hook? Not so much.
I built a C#/C++ program in grad school that intercepted keystrokes intended for another application, but I was only able to do it by waiting for the desired application window to open, auto-opening my own pop-up window to receive the input, and then passing keystrokes back to the original window.
I'm not saying it can't be done, period, but my background knowledge (though slightly dated) and a little cursory research isn't turning up anything in the basic scripting world that would satisfy what you appear to be after.
The only way I know how to do it (which is likely wrong) would be to have hooks in every open application, and when a textbox on the application gained focus give focus to your own text-receiving app. Analyze the keypresses, and then pass the desired text/keypresses on to the original app/textbox. This would require prior knowledge of the "windows" (i.e. all objects) in all possible apps on the machine you're working on, so you would know when a textbox received focus.
If I recall, it might be possible to tell when keys are being pressed (if you have hooks in all apps) and re-direct from there, but you might lose the first keystroke, even then.
Again, this is primarily speculative.
Soon I will have to work with OS X and tools like hammerspoon are missing some important capabilities for me. I need to be able to intercept keyboard and mouse events completely from the focused application. Say I ctrl+alt+apple+left_click on an application, I don't want the application to know about that left click. So far the only thing I came up with was to build a transparent fullscreen application, though I'm not sure how feasible that is yet.
Any better idea or hints how to go about this in a language of your choice?
Thanks!
You will need to create an event tap. However, the application will have to run as the root user, or the user will have to authorize that the application has been granted rights to accessibility features.
Apple's documentation can be found here.
Interestingly enough, I am in the process of writing a blog post about how to use event taps (including an ObjectiveC API that I wrote for my own use), but the post won't be made available for another week or so.
I am writing a program to sit in the background on osx 10.6, listen to keystrokes and record them, grouping them by window title. (No, I am not writing malicious software. I do not need this program to be sneaky in any way, I just want to have a safety net for when I have typed a huge email and then accidentally refresh the page (APPLE-R) instead of opening a new tab (APPLE-T)) I have already found apple's EventMonitorTest example for the keystroke capturing code, now I just need to find the "key window" title.
Does anyone know where I can find examples for this kind of functionality? Thank you!
A couple of possibilities:
You could use the Accessibility API (though of course keep in mind that 64-bit Carbon does not support this)
You could use the CGWindow functions introduced in Leopard
I suspect the first option will be easier to do this with, since the CGWindow API is somewhat low-level and treats all windows (application windows, menu bars, dock icons, etc.) more or less equally.
I'm writing a Cocoa application that installs itself as an menulet in the menu bar (i.e. like the volume or battery icons). When the program crashes, it isn't possible to use the Force-Quit dialog, because it doesn't show up in the list. Of course, I can still kill it using the command-line, but my users don't know how to do that. Is there any way to fix this, say by making the program show up in the Force-Quit dialog?
(Note: the app is Leopard only).
To be honest, the proper solution is to make sure your app never hangs or crashes for users. This should be your #1 priority, rather than figuring out how to let users deal with crashes and hangs. Obviously it isn't always possible to make sure your app never breaks in these ways, but it should definitely be the exception rather than the rule.
On another note, MenuExtras is a private API which I hope you aren't using to create your "menulet". Rather, the public class NSStatusItem (part of Cocoa) is the Apple-approved, recommended way to install icons into your menu bar.
Not really an answer, but hopefully helpful still ...
I think that most people who know how to force quit also know they can kill a process in the activity monitor. Just make sure it's not named '93AZkZ' or something.
You could provide a PreferencePane for your application that can send the proper signal to it, if you want to allow users an easy way to shut it down or restart it. This is the pattern that MySQL uses on OS X.
I'm writing a routine to provide user definable keyboard short-cuts for any menu item in my Windows Mobile 5 application, which is in C++/MFC. To do this I am getting all of the available menu command IDs, and using the CWnd::PostMessage(WM_COMMAND,MyMenuID) to post it to the application. I use this technique to good effect elsewhere for inter-thread comms, but not with menu command IDs. Any ideas why this doesn't work. The app is document view, and I have tried posting to the CMainFrame and CView derived windows. I could write a god awful switch statement but I feel posting a message should work.
Edit: Ok, i've tried a number of things, including suggestions from this post, to no avail. Big ugly switch statement it is for now, I'll update again if i find anything better.
The only reason I can think of is the message is going to the wrong window. Don't forget that not all menu commands are always processed by a particular window. Some menu commands like Cut are usually processed by a view window. Others are processed by frame windows and some possibly by the application object.
Hope this helps.