views:

411

answers:

1

In an iPad app, I'm using a custom subclass of UIView with UIViewController. Here's the view header:

@interface pdfView : UIView {
    CGPDFDocumentRef doc;
}

-(void)setDoc:(CGPDFDocumentRef)newDoc;

@end

And here's the controller header:

@interface iPadPDFTestViewController : UIViewController {
    CGPDFDocumentRef doc;
}

- (void)loadPDF;

@end

Part of the controller implementation:

- (void)viewDidLoad {
    [super viewDidLoad];
    [self loadPDF];
    [self.view setDoc:doc];
}

In Interface Builder, I've set the view object to use the class pdfView.

At compilation, [self.view setDoc:doc]; gives the warning "'UIView' may not respond to '--setDoc'." I'm guessing that this warning appears because the compiler thinks it's looking at UIView (which does not implement the setDoc method) instead of pdfView. But why does it think that? And how can I tell it what class it's really looking at, so as to clear the warning?

+4  A: 

The compiler only knows what the code defines, and a UIViewController defines it's view property as a UIView, which is why you're seeing warnings.

You can avoid warnings by casting the view to your PDFView: (PDFView *)self.view;

To make this simpler implement a basic getter method

- (PDFView *)view {
    return (PDFView *)self.view;
}

Also, just as a side note, you should really name your classes so they start with atleast one uppercase char, and ideally a prefix (i.e. PDFView, ideally MYPDFView (where MY is a custom prefix)).

dannywartnaby
For a little deeper treatment of @dannywartnaby's important point about prefixing class names in Objective-C to prevent namespace collisions: http://stackoverflow.com/questions/178434/what-is-the-best-way-to-solve-an-objective-c-namespace-collision
Barry Wark
Thanks! That worked like a charm. Your explanation was very helpful--I see now that the compiler is getting its type information from the definition of the `view` property. What I'm doing now is this: `[(PDFView *)self.view setDoc:doc];`