I'm following Udemy videos and this error is showing up even after importing the header file. The guy in video also gets the error but that was before importing the header file.
Edit
#import <UIKit/UIKit.h>
#import "TADFoodTableViewController.h"
#interface TADAddFoodViewController : UIViewController
#property (nonatomic,weak) TADFoodTableViewController *foodTableViewController;
#property (weak, nonatomic) IBOutlet UITextField *foodTextField;
- (IBAction)addFoodButtonPressed:(id)sender;
#end
You have sucked in import cycle. When we import file 1 in file 2 and try to import file 2 in file 1 then, such errors occur. Try using
#class TADFoodTableViewController.h;
or import it in .m
i think you should be take (strong,nonatomic) may be will work.
Related
I'm trying to add the FBLoginViewDelegate protocol like this:
#import <UIKit/UIKit.h>
#import <FBSDKLoginKit/FBSDKLoginKit.h>
#interface ViewController : UIViewController<FBLoginViewDelegate>
#property (weak, nonatomic) IBOutlet FBSDKLoginButton *loginButton;
#end
However, I'm getting Cannot find protocol declaration for 'FBLoginViewDelegate'
I've added the FBSDKLoginKit.framework to my Xcode project.
These two answers say to add FacebookSDK.framework to my project and import it:
How to make Xcode find file FacebookSDK.h?
Cannot find protocol declaration for 'FBLoginViewDelegate'
However, the zip that I downloaded and extracted doesn't have a FacebookSDK.framework in it. Here is what I have:
and I downloaded it from Facebook here:
https://developers.facebook.com/docs/ios/getting-started
Does anyone know how I can fix this? Or why I don't have FacebookSDK.framework? Thanks!
Change <FBLoginViewDelegate> to <FBSDKLoginButtonDelegate>.
<FBLoginViewDelegate> is in the previous version of SDK. The current is <FBSDKLoginButtonDelegate>
I have this code a Custom class which extends UIImageView in Objective-C.
When I add to the project and add import to bridging header file my swift class can see
and use the code as usual but when i try to compile it.
I always get this error
I don't know why it is only happen to my CarBigImageView, I try to change the name of the file , create new file with new name and copy all the code there but none seem to work.
but other custom view such as Marker seem to be fine?
UPDATE : ADD MORE INFORMATION
here is my bridging header
#import <AFNetworking/AFNetworking.h>
#import <AFNetworking/UIImageView+AFNetworking.h>
#import <GSKeychain.h>
#import <JSONKit.h>
#import "CarBigImageView.h"
#import "sqlite3.h"
#import <time.h>
#import "Bridge.h"
#import "Marker.h"
here is my "CarBigImageView.h"
#import <UIKit/UIKit.h>
#protocol CarBigImageViewDelegate <NSObject>
- (void)didTouchColor:(UIColor*)coloc atPosition:(CGPoint)point;
#end
#interface CarBigImageView : UIImageView
#property (weak, nonatomic) id<CarBigImageViewDelegate> delegate;
#end
and here what it looks in the editor
and the result when compile
How can i solve this?
Make sure you left Xcode know where to find that file: in build settings look for "Objective-C Bridging Header". The value for that field should be something similar to "$(SRCROOT)/path/to/your/Bridging-Header.h" If you fill this out and hit enter, it SRCROOT will expand, and you can check if that full path is correct path.
I'm trying to follow this tutorial: http://docs.opencv.org/doc/tutorials/ios/video_processing/video_processing.html
I have followed the steps but in the viewController.h file, it tells you to type "using namespace cv;" near the top of the file.
Xcode sees this as an error. And it won't let me build. How do I fix this?
Using XCode 4.6.3 and I can't tell what version of openCV I'm using but I just downloaded, so it's probably the latest. Also, I know that I've imported the opencv framework.
Here are the lines of code in viewController.h:
#import <UIKit/UIKit.h>
#import <opencv2/highgui/cap_ios.h>
using namespace cv;
#interface ViewController : UIViewController
#property (weak, nonatomic) IBOutlet UIButton *button;
#property (weak, nonatomic) IBOutlet UIImageView *imageView;
- (IBAction)actionStart:(id)sender;
#end
Try changing the extension of your ViewController from .m to .mm. That signals to the compiler that you would like to write that piece of code in Objective C++.
Edit: For additional information on how to write code effectively this way, check out this blog post.
I’m getting run time error as duplicate interface definition for class app delegate.So what is the wrong with this code.
#import <UIKit/UIKit.h>
#class ViewController;
#interface AppDelegate : UIResponder <UIApplicationDelegate>
#property (strong, nonatomic) UIWindow *window;
#property (strong, nonatomic) ViewController *viewController;
#end
At the begin of your header file state:
#if !defined APPDELEGATE_H
#define APPDELEGATE_H
and at the end state:
#endif
Most probably root cause of this error is that you included AppDelegate.h in some classes header file and .m file. While compiling the .m file the corresponding .h file is included (and probably some other .h files are included). In any of these .h files AppDelegate.h is included. Plus you include it in the .m file. That will cause a duplicate definition of the interface from the compiler's point of view.
The solution above is not really a solution. Strictly spoken it is a workaround. But it is quite standard and apple uses it in all of their templates. It's just a workaround because it does not solve the issue but deals with it.
Proper solutions would be:
In the .h file do not include other .h files if avoidable. Use #class statemenst where ever appropriate.
Never repeat incuding of any .h file in a .m file when the .h file is already included in any of the other included .h files.
You may think "this is a pain in the a....". And you are right :) Therefore I suggest to use the common #if !defined XY_H / #define XY_H / #endif pattern, although I believe that this is just a workaround.
#if !defined APPDELEGATE_H
#define APPDELEGATE_H
#import <UIKit/UIKit.h>
#class ViewController;
#interface AppDelegate : UIResponder <UIApplicationDelegate>
#property (strong, nonatomic) UIWindow *window;
#property (strong, nonatomic) ViewController *viewController;
#end
#endif
I just ran into this problem.
What I had done was to drag and drop files that had an #import AppDelegate from another project that also contained the exactly named AppDelegate.h/.m class. When I dropped the files into my project I REFERENCED them from that project instead of COPYING them.
By doing so, those files were in conflict which AppDelegate to import and I got a compiling error saying 'duplicate interface definition for class `AppDelegate.
I resolved the problem by removing the reference and copying the files as intended. This might not be your problem since you had a run time error, but just a heads up.
I was just wondering if it's considered bad practice to have a large number of header files imported into an AppDelegate?
My game has a lot of views (in separate .xib files) that the AppDelegate switches between. At the moment, I am importing 16 header files in my AppDelegate.h file, but is there a better way to manage all of this? Most sample code I've seen has a maximum of around 4 or 5 header files.
Thanks!
It's usually better practice to forward declare your classes in the header file, and then import their headers in your implementation file, for example:
// .h
#import <UIKit/UIKit.h>
#class MyView;
#class MyOtherView;
#class MyOtherOtherView;
#interface MyAppDelegate : NSObject <UIApplicationDelegate>
#property (strong, nonatomic) MyView *myView;
#property (strong, nonatomic) MyOtherView *myOtherView;
#property (strong, nonatomic) MyOtherOtherView *myOtherOtherView;
#end
// .m
#import "MyAppDelegate.h"
#import "MyView.h"
#import "MyOtherView.h"
#import "MyOtherOtherView.h"
#implementation MyAppDelegate
#synthesize myView;
#synthesize myOtherView;
#synthesize myOtherOtherView;
// methods
#end
Doing this will help to avoid situations where you will end up with circular #import references.
I will also often create a header file simply for importing other header files for clarity, e.g. #import "MyViews.h"
Sample code is just that -- sample code, usually meant to clearly demonstrate a single concept. Don't expect your application to look like sample code if it does more than one single relatively simple thing. Expect it to look more like several dozen sample projects all put together (although I wouldn't advise doing exactly that!).