Well, I suppose I could make sure the window's contentView is not layer backed and then put all of the content that used to be in that view into a new layer-backed view and then add the new layer-backed view as a subview of the contentView.
Next, I create my layer-hosting view and add it to the contentView as a subview, making it a peer of the layer-backed view. Is that what you mean by restructuring the view hierarchy? -Michael On Jul 19, 2011, at 23:44, Scott Anguish <sc...@cocoadoc.com> wrote: > > On Jul 19, 2011, at 12:27 PM, Michael Crawford wrote: > >> Graham; Scott, >> >> I have a follow-up question on this topic, if you don't mind. Do either of >> you have a recommendation on the idea of adding a layer-hosting view as a >> subview of a layer-backed view? > > Yes. You shouldn’t. > > When you turn on layer-backing for a view, you turn it on for the entire > subview hierarchy. So none of those layers are your’s to mess with. Typically > the way around this is to restructure the view hierarchy some. > > >> I'm thinking of adding a virtual keyboard to an existing app that is >> layer-backed. I would like this VK view to have all the benefits that >> NSView brings including event handling without all of the heavy-weight of >> multiple subviews for the keyboard mechanics. >> >> Can I mix these? >> >> (Please reply to the thread for everyone's benefit.) >> >> -Michael >> >> On Jun 22, 2011, at 3:02 AM, Scott Anguish wrote: >> >>>> Yep, I'm aware of the setWantsLayer/setLayer order making a difference. >>>> >>>> In my case I want a layer-hosting view, not a layer-backed view. >>>> >>>> However, my question isn't really about that, but about what is done when >>>> you check the box next to the layer in Interface Builder, in the >>>> 'setWantsLayer' panel. Does this provide layer backing or layer hosting? >>>> My thoughts were that is provides layer hosting, but I'm not 100% sure. >>>> Proceeding on the basis that this is the case, it seems to work. >>>> >>> >>> layer-backed. >>> >>> >>> >>> >>>> >>>>> Again this is not in line with my expectations, which is that the frame >>>>> of a sublayer is expressed in the coordinate system of its superlayer, >>>>> not the underlying window. >>>> >>>> I found the cause of this issue, which was that in my layer delegate, I >>>> was not saving, setting and restoring the context passed to >>>> drawLayer:inContext:. I was assuming that the context was set, but having >>>> found a code snippet in the docs that indicated it wasn't, I added these >>>> calls and my graphics are drawing in the right place now. >>>> >>> >>> great!_______________________________________________ >>> >>> 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: >>> http://lists.apple.com/mailman/options/cocoa-dev/michaelacrawford%40me.com >>> >>> This email sent to michaelacrawf...@me.com >> > _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
