Re: Views & Staying On Top / Accessing Across Apps
Re: Views & Staying On Top / Accessing Across Apps
- Subject: Re: Views & Staying On Top / Accessing Across Apps
- From: Jens Alfke <email@hidden>
- Date: Sat, 19 May 2012 11:51:34 -0700
On May 18, 2012, at 4:10 AM, Jason Teagle wrote:
> Out of interest, do NSView or any other class that would be considered 'visual' support any kind of stay-on-top semantics (or slightly less specifically, stay-in-front-of-another-view semantics) without actually being a subview? Docking (without specific support from the owning application to implement the feature - I'm talking about built into the framework)?
A view is always clipped to its parent, so such a view would have to be a direct child of the window's contentView, and would have to be ordered in front of its siblings. There might or might not be issues with the sibling views redrawing correctly.
Another way to accomplish this is by adding a "child window", which is a window that follows its parent around and always stays directly in front of it (this is how things like pop-up menus, tooltips, sheets and drawers are implemented.) If you don't give it a window frame, it can have arbitrary shape and content.
> Another view / window question: Is it possible to access the views / windows of another application, with the intention of moving / sizing them (and, if a stay-on-top / -in-front flag is supported, setting that)?
Well, sort of. There is an Accessibility API that (if the user enables this feature) can let your app look at the UI elements of other apps and manipulate them to some degree. It doesn't let you put arbitrary stuff into another app (for one thing, that would require injecting your code into its process.)
> (If you're wondering, I'm thinking along the lines of a utility that would add sticky / docking facilities to the views / windows of an app that otherwise doesn't support it.)
I'm doubtful this can be done; or at least, if it can, it would require some very tricky hacking (i.e. injecting code into other apps.) Definitely not a newbie project, I'm afraid.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden