> On Apr 23, 2016, at 8:27 AM, Dave <d...@looktowindward.com> wrote: > > Because my window is a “Floating Window” it floats above the Windows of ALL > applications, I want it to just float above the window in the App it is > pinned to.
Theoretically, you could do this with the Accessibility API. Instead of using a small overlay window that is sized the same as the target application's window and moves with it, create a stationary overlay window that covers the entire screen (all screens, in a multi-monitor situation). The overlay window should be transparent except for the small part that lies directly over the target application's window. Use drawRect or similar to redraw the visible part of your overlay window in the right location and size to cover the target application's window while the target application's window is moved or resized. And here's the "just float above the window" part: Redraw the visible part of your stationary overlay window so that the areas where the target application's window is obscured by other application windows or system windows is transparent. This will create the illusion that your overlay window is being obscured by the other application windows or system windows. This of course requires you to keep track of which application and system windows are in front of the target application's windows, and their locations and sizes, but you can do that with the Accessibility API. I say "theoretically" because I don't know whether monitoring the other application and system windows would slow you down too much. The speed issue will be affected by how you move and resize your small overlay window, or how you move and resize the visible part of your full-screen overlay window if you do it that way, in sync with the movement of the target application window. In UI Browser, which has a small overlay window to "highlight" the target application window or other UI element, I achieved the best speed I could by a combination of the Accessibility API and Quartz Event Taps. The problem with the Accessibility API is that it does not track window movement or resizing continuously. I forget which function it is, but you can look it up. Basically, it coalesces calls to get the target application's window position and size so that only a few calls per second actually get through. You can work around this with Event Taps notifications, which are not similarly coalesced. Even with that trick, the overlay window in UI Browser is not quite perfectly synced with the target application's window when it is moved really fast. I even offer a preference setting that allows you to create a visible but very smooth animation lagging behind the target application window's movement, because in UI Browser I am not trying to fool the user into thinking the overlay window is part of the target application. However, I suspect (but don't know for sure) that using drawRect on a stationary full-screen window to move the visible portion will be much faster than moving a small overlay window, because you won't have any of the window movement overhead. I've never gotten around to trying that in UI Browser. -- Bill Cheeseman - wjcheese...@comcast.net _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
