On Mar 19, 2012, at 10:41 PM, Jean-Philippe Ouellet wrote: I can send mouse click events via CGEventPost() just fine, but that requires the target window to have focus (which I am trying to avoid).
Since nobody in authority has responded, I'll give it a shot.
Your code looks just right. Unfortunately, I don't think event taps can do what you want, because what you want is contrary to the purposes and goals of accessibility. (I would be pleased if somebody could prove me wrong.)
Based on the introduction to the Quartz event taps documentation, event taps are a Section 508 technology (referring to section 508 of the Americans with Disabilities Act). Thus, event taps is an accessibility API, and this list is perfectly appropriate for discussing it. If you don't get a reply here after a while, then it's also appropriate to ask again on the quartz-dev list. At least, that's the way I've been doing it for the last 8 or 10 years.
Apple's basic philosophy regarding accessibility is that the system should make it possible for persons with disabilities to do what others can do on the computer, but no more than that. As a result of this philosophy, there are lots of things that you and I might like to be able to do with the accessibility API and event taps, but which Apple does not and will not support as a matter of principle.
In this case, Apple's philosophy says that event taps cannot cause your synthetic mouse click to go through another application's window that is layered in front of your target application's window. Why? Because a non-disabled user cannot do that with a real mouse click.
What I assume is happening with your code is that, at least in concept, your call to the CGEventPostToPSN function does in fact send the mouse event to the targeted background application. The background application then dutifully clicks the mouse at the designated point on the screen. The click then interacts with whatever application's UI element is visible at that point on the screen. If the visible UI element at that point belongs to some application that is in front of your target application, then the more-frontmost application responds to it -- just as would happen with a real mouse click at that point on the screen.
One workaround is, as you suggest, to bring your application to the front momentarily. In my experience, this works, and it often doesn't cause a flicker on the screen. Sometimes other workarounds are possible, depending on what you are trying to do. For example, if you intend your synthetic mouse click to push a button in your application's window, and that button has a keyboard equivalent, then send a keyboard shortcut command to the target application instead.
|