Cannot find protocol declaration for 'NSPasteboardWriting' - iphone

I am getting this error
Cannot find protocol declaration for 'NSPasteboardWriting'
i have created the class
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#interface ErrorLog : NSObject<NSCoding, NSPasteboardWriting, NSPasteboardReading> {
}
#end
Can any one tell me that whether i am missing some header file or whats the reason for that?

NSPasteboardWriting is Available in Mac OS X v10.6 and later.
check your project setting(Base SDK).

Import the header file in which NSPasteboardWriting and NSPasteboardReading protocols are declared. Also make sure you have the protocols in the class specified.

Related

Headers #import versus #class [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
#class vs. #import
In the .h file you can add a class to be seen(dont know what the correct terminolgy for this is) by using
#import "SomeClass.h"
or instead use
#class SomeClass;
I've tried both methods and they both worked. Whats the difference? Should I be using one of the methods and not the other? What is best practice?
#import includes the content of the header in the source.
Thus, every declaration which is in the imported header is also imported.
#class only declares to the compiler that the given class exists, but does not import the header itself. It is called a forward declaration, as you only declares to the compiler that the class exists before defining it in details (telling which methods it implements and so on)
Consequences:
When using #import in your .m file, if the header is modified, it will trigger the recompilation of the .m file that #import it on next compilation. Instead, if you use #class, your .m does not depend on the header and if the header is modified, the .m file is not recompiled.
Using #class also avoid cross-imports, e.g. if the class A references class B and class B references class A, then you can't #import "A.h" in B.h and #import B.h in A.h in the same time (it would be an "import infinite loop")
Using #class only declare that a class exists and does not tell the compiler which methods the class responds to.
This is why usually the best practice is to forward-declare the class using #class A in the header (.h) files that references class A, just so that the compiler knows that "A" is a known class but doesn't need to know more, and #import "A.h" in the implementation (.m) file so that you can call methods on the objet of class A in your source file.
In addition to avoid import loops, this will also avoid to recompile files if they don't need to, and thus reduce your compile time.
The only exceptions are when the declaration of your class inherits another class, or when it declares that it conforms to a given #protocol (like delegate protocols and so on), because in this particular case, the compiler needs you to #import the whole definition of the parent class or #protocol (to know if your class correctly conforms to this given protocol).
MyClassA.h
// Tells the compiler that "MyClassB" is a class, that we will define later
#class MyClassB; // no need to #import the whole class, we don't need to know the whole definition at this stage
#interface MyClassA : NSObject {
MyClassB* someB; // ok, the compiler knows that MyClassB is a class, that's all it needs to know so far
}
-(void)sayHello;
-(void)makeBTalk;
#end
MyClassB.h
#class MyClassA; // forward declaration here too
// anyway we couldn't #import "MyClassA.h" here AND #import "MyClassB.h" in MyClassA.h as it would create an unsolvable import loop for the compiler
#interface MyClassB : NSObject {
MyClassA* someA; // ok, the compiler knows that MyClassA is a class, that's all it needs to know so far
}
-(void)talk;
-(void)makeABePolite;
#end
MyClassA.m
// import MyClassB so that we know the whole definition of MyClassB, including the methods it declares
#import "MyClassB.h" // thus we here know the "-talk" method of MyClassB and we are able to call it
#implementation MyClassA
-(void)sayHello { NSLog(#"A says Hello"); }
-(void)makeBTalk {
[someB talk];
// we can call the 'talk' method because we #imported the MyClassB header and knows this method exists
}
#end
MyClassB.m
// import MyClassA so that we know the methods it declares and can call them
#import "MyClassA.h"
#implementation MyClassB
-(void)talk { NSLog(#"B is talking"); }
-(void)makeABePolite {
[someA sayHello];
// we can call this because we #import MyClassA
}
#end
PS: Note that if this is a best practice, I know a lot of developers (including myself sometimes ^^) that #import the header it needs in their .h files, instead of only forward-declare it using #class... this is some bad habit — or because these developers doesn't know these subtleties — that you will unfortunately encounter in existing code anyway.
Using #class is called forward declaration. Since usually you don't need to know the specifics of the class in the .h file, this is usually all you need.
Forward declaration prevents you getting into a situation where you import a particular .h file, which says to import another .h file, which says to import the original .h file again, and so on.
The #class forward declaration allows you to have your interfaces behave like interfaces. Meaning: Declare your code.
But this doesn't mean that you can leave out the #import statement. You just moved the responsibility to the implementation to import and make use of it.
Basically it could be seen as an increase in performance as you're not importing any other headers inside your current header.
Important Note: This isn't the case when you're working with delegates.
If you're making use of delegates you always have to have the proper #import statements in place so that the compiler knows which delegate methods are to be implemented by that class.
You might also want to have a look at the following SO question: #class vs. #import

How can you conditionally include protocols during compiliation?

Is it possible to conditionally include a protocol? For example, below is some code that does not work, but should give you an idea what I'm referring to. I only want the interface AdWhirlDelegate to be included if ads are turned on.
// this works fine
#if ADS_SUPPORTED
#import "AdWhirlView.h"
#endif
// this does NOT work
#interface MyAppDelegate : NSObject <UIApplicationDelegate #if ADS_SUPPORTED ,AdWhirlDelegate #endif>
You could do:
#if ADS_SUPPORTED
#interface MyAppDelegate : NSObject <UIApplicationDelegate,AdWhirlDelegate>
#else
#interface MyAppDelegate : NSObject <UIApplicationDelegate>
#endif
...but then IB can get a little confused. See this answer, which presents an alternative to that.
That won't work
Repeat the interface declaration twice , one with the protocol and one without blocked inside the #if/#else/#endif structure
Preprocessor directives will only work in a non nested way like your header include.

Protocol definition not found

I am having a little trouble with getting a protocol definition to work, and this must be a stupid mistake. I included the header in which the definition is located, but I got the warning, so followed the advice to create a separate header file. I still get the warning that the definition cannot be found (when importing this separate file), and even when I put the definition in the header file of the class using it it gives the warning:
#protocol SubstitutableDetailViewController <NSObject>
- (void)showRootPopoverButtonItem:(UIBarButtonItem *)barButtonItem;
- (void)invalidateRootPopoverButtonItem:(UIBarButtonItem *)barButtonItem;
#end
#interface LauncherViewController :TTViewController<SubstitutableDetailViewController, TTLauncherViewDelegate> {
TTLauncherView *launcherView;
}
So what do I do wrong in my definition of the protocol?
[EDIT: Sorry, there must be an oddity in Xcode, or I am going mad, I did a clean build and now the warning does not come back... but I don't know why]
Put this code in a separate file named SubstitutableDetailViewController.h (I'd prefer SubstitutableDetailViewControllerDelegate.h):
#protocol SubstitutableDetailViewController <NSObject>
- (void)showRootPopoverButtonItem:(UIBarButtonItem *)barButtonItem;
- (void)invalidateRootPopoverButtonItem:(UIBarButtonItem *)barButtonItem;
#end
And then include it in LauncherViewController via #import "SubstitutableDetailViewController.h"

Expected Specifier qualifier list error

Hey guys, I know this problem caused due to the absent of importing header
But in my case, I've included the header but I still got the error?! What happens?
#import <Foundation/Foundation.h>
#import "WikitudeARCustomMenuButtonDelegate.h"
#import "DetailedARViewController.h"
#interface CustomMenuButtonDelegateImpl1 : NSObject <WikitudeARCustomMenuButtonDelegate>
{
DetailedARViewController *ARViewController;
}
#end
Make sure that "DetailedARViewController.h" really does define DetailedARViewController; in particular, check for subtle errors like misspellings or a declaration accidentally commented out.

#import statements in .m or .h in objective-c?

I ended up having these in both of my .h and .m files, this is my first Objective-C program so I'd like some clarification so I can clean thins thing up.
Unless it affects the interface definition you should put it in the .m file.
If you just use a class, use a forward declaration:
#class AClass;
#interface Bob : NSObject {
AClass* a;
}
If you implement something, then import it:
#import "SomeProtocol.h"
#interface Bob : NSObject<SomeProtocol> {
}
These kinds of thing are really "best practice" rather than absolutely essential. Objective C's #import directive means that you can't get errors because you include a file multiple times, so it's not technically a problem, but it will increase compile times.
These are the rules I follow:
If in your header file, you only need to use pointers to classes declared in the header file you are including, then I would just use a class sentence on the header file (.h) and full import on the definition (.m) file.
If you need to use full definition of some stuff on the header file you are including, then the full import goes into the header file.
For the examples, consider files MyClass.m, MyClass.h and MyInclude.h:
Example, scenario #1:
// MyClass.h
#class MyInclude;
#interface MyClass : NSObject {
MyInclude *myIncludeObj;
}
// MyClass.m
#import "MyClass.h"
#import "MyInclude.h"
Exaple, scenario #2:
// MyClass.h
#import "MyInclude.h"
#interface MyClass : NSObject {
MyInclude myIncludeObj; // MyInclude could be a plain C structure
}
// MyClass.m
#import "MyClass.h"
The #import directive is an improvement over the #include directive in that instead of blindly copying the file in place, it will not include it if it has already been included. Therefore you shouldn't experience any problems with #import-ing the same file multiple times.
As far as best practice goes, IMHO it's best to keep the scope as narrow as possible. Therefore I'd suggest putting your #imports in you implementation files (.m). If you require the class definition in your interface file (.h) then you can use the
#class MyClass;
construct to inform the compiler that it will be able to find the relevant header in the implementation file.
Hope this helps.
I have just one rule: Import at the top of the .h file for the superclass and protocols of any classes you declare in the .h file. This is because any file that imports your .h file also needs the declarations for the superclass and protocols. This is also why the default Xcode template has #import <UIKit/UIKit.h> in the .h file rather than the .m file.
For everything else (e.g. types used for ivars and method parameters), use forward-declarations and put the #import in the .m file
Another way to put this is: never use forward declarations for superclasses and protocols.
Best practices is to put #import statements in .m files. If you need access to a class inside the header file, for a property declaration or a function parameter, use a forward declaration, like this:
#class Cocos2DController;
#interface HoppersAppDelegate : NSObject <UIApplicationDelegate> {
Cocos2DController* controller;
}
A forward declaration lets the system know that the class exists, though it's not yet fully defined. With this pattern, you'll keep your headers lean, and guarantee that you're only importing the headers that you want for a specific class, not chaining #imports all through the application.
For a specific problem you might run into: If you include #import statements in a header file, you run the risk of an #import loop if two classes import each other's header files.