You do want your subviews drawn, right? -- Gary L. Wade http://www.garywade.com/

I’ve gone for something slightly different that’s a little more generic (it’ll work for any view, not relying on it being a specific class). It still wouldn’t work for a layer backed or

Cool - I’ll give that a shot. Thanks! —Graham

I’ve never called super, nor understand why it would be needed. I know the boilerplate calls it, but it appears to do nothing. If there has been a change in the recommendation for this since 10.2

Looking at the code, it appears you’re missing a call to [super drawRect:dirtyRect] in your own drawRect: method. -- Gary L. Wade http://www.garywade.com/

Works, too!

Oh, of course, by calling their drawRect, it makes them draw in parent bounds coordinates, not their own bounds coordinates, but you can compensate for that.

An interesting observation. I went back to your test project and made the digit-array drawRect call drawRect on the subview, and they draw in IB! Unfortunately, they draw in the wrong place. If you

Yes - the view works properly in the normal runtime case. I’ve determined that the reason is that the IB ‘agent’ for previewing an IB_DESIGNABLE view directly calls -drawRect: on the view - it

Hi Graham, Are you setting needsDisplay for each of the subviews? Jeremy

Thanks for having a look, I see what you’re saying, but IB has to instantiate the view (at least once) to capture what it renders. It must also redo this capture whenever any of the properties

AFAICT it doesn’t work like that. The canvas isn’t showing the view hierarchy, it’s showing the objects in the design hierarchy that you can reveal on the left. Of course, that represents the

Hi all, I’m working on a small custom view project (Mac), and have it working generally quite well. I decided to make it IB_DESIGNABLE, and that too mostly works - I can see the view in IB rendered

(I tried to find Charles’s post about this, but didn’t succeed.) Everything you said after the first sentence is absolutely true. That is the standard way, and your suggestion helped rewrite the

I disagree that it's dangerous. It's the standard way code is written when a parameter is passed back by reference. How many times in Apple code do you see something like: NSError* err; if([thing

So, here’s what’s going on. It’s a bit messy. — A pointer has an ownership attribute, which is __strong by default, but can be explicitly specified as __weak or __autoreleasing. In your code,

Excellent. Works perfectly without complaints from the compiler. Thanks a lot! Kind regards, Gerriet.

Yes. Why not this? NSString* s; NSUInteger c = [self computeFor:42 reason:needReason ? &s : nil]; -- Steve Mills Drummer, Mac geek

I have a method like (macOS 13.3, Xcode 9.2 (9C40b)): - (NSUInteger)computeFor: (NSUInteger)arg reason: (NSString * __autoreleasing *)reason { NSUInteger value; // some computing… if ( reason

https://developer.apple.com/library/content/technotes/tn2265/_index.html https://developer.apple.com/library/content/technotes/tn2265/tn2265_PersistentConnectionLogging.zip Testing on the Mac to see