Very good answers, many thanks! What great info. I suspected something like this, of course. But then I'd like to complain about the documentation; I shouldn't have had to discover this by stubbing my toe against it (or, getting tingly water, as Glenn puts it).
Where are the warnings? We're working with CALayer so that's where they need to be. Here's what we find under CALayer's delegate property: "In iPhone OS, if you want to assign a UIView object to this property, you must assign the view whose layer this is. Assigning a a superview of the layer's view will cause your application to crash during drawing." Well, fine. But I'm *not* assigning a UIView object to this property. I'm assigning an NSObject object. So I expected everything to be okay. Not a word here about how the UIView's layer is special. And in this document: http://developer.apple.com/mac/library/documentation/cocoa/conceptual/CoreAn imation_guide/Articles/ProvidingCALayerContent.html ...we are invited to set a delegate as a way of drawing directly into a layer by means of drawLayer:inContext:. Not a word about how you can't just set any old delegate for any old layer. The warning in the UIView class doc page is good, but this is not the only place where this warning needs to be, because this is not the only direction from which the matter might be approached. And I don't find anything in the docs as clear as Luke's brilliantly incisive explanation of the view tree (it might be there somewhere, but I sure didn't stumble across anything like this as I was putting together my code). All I was trying to do was save a little memory by not bothering to create a bitmap and draw into it; I was just looking for a way to draw directly into a layer's context (without subclassing). This seems like an innocent enough thing to want to do... m. On or about 8/12/10 4:36 PM, thus spake "Luke the Hiesterman" <luket...@apple.com>: > UIView does not maintain a tree. The view tree is really a CALayer tree, where > some (or all) of the layers belong to UIView instances. This tie is made by > the fact that UIView is the layer's delegate. Thus self.subviews is really > self.layer.sublayers for each layer whose delegate is a UIView. Long story > short, don't change the layer's delegate. If you want to act as a layer's > delegate you should create a CALayer instead of a UIView and then do > [self.view.layer addSublayer:layer]; > > On Aug 12, 2010, at 4:28 PM, Matt Neuburg wrote: > >> Here's my code, simplified (and tested in this simple form) in order to >> demonstrate a mystery: >> >> - (void) illuminate: (NSArray*) arr { >> UIView* v = [[UIView alloc] initWithFrame:self.view.bounds]; >> NSLog(@"%@", v); >> CALayer* lay = [v layer]; >> v.tag = 111; >> [self.view addSubview:v]; >> lay.delegate = self; // <-- *** >> [v release]; >> [self performSelector:@selector(unilluminate:) >> withObject:nil afterDelay:0.2]; >> return; >> } >> >> - (void) unilluminate: (id) dummy { >> for (UIView* aview in [self.view subviews]) >> NSLog(@"%i %@", aview.tag, aview); >> } >> >> The mystery is what we learn in unilluminate from logging: >> >> (1) the UIView "v" is *not* among the subviews of self.view; >> >> (2) but it *is* among the subviews of self.view if we comment out the >> starred line (lay.delegate = self). On or about 8/12/10 4:38 PM, thus spake "glenn andreas" <gandr...@mac.com>: > Don't do that. > > From > <https://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIVi > ew_Class/UIView/UIView.html#//apple_ref/doc/uid/TP40006816-CH3-SW31> > > Warning: Since the view is the layer¹s delegate, you should never set the view > as a delegate of another CALayerobject. Additionally, you should never change > the delegate of this layer. > > Basically you're break the underlying plumbing, connecting the cold water to > the electrical, and wondering why your water tastes tingly... -- matt neuburg, phd = m...@tidbits.com, http://www.tidbits.com/matt/ pantes anthropoi tou eidenai oregontai phusei Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf AppleScript: the Definitive Guide, 2nd edition http://www.tidbits.com/matt/default.html#applescriptthings Take Control of Exploring & Customizing Snow Leopard http://tinyurl.com/kufyy8 RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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
