I thought the following would populate my home variable with my HomeViewController
var home = self.parentViewController!.parentViewController! as HomeViewController;
Instead I get the following compile error 'Use of undeclared type HomeViewController' although it definitely exists and appears in the auto complete popup.
Often XCode6 displays the wrong error message. Is this an instance variable? It may be that parentViewController isn't set at init time (the fact that it's an implicitly unwrapped optional strongly suggests this). If this is in a function, I'd do this in an if let statement to give us a better sense of what's going on. Something like:
if let homeVC = self.parentViewController?.parentViewController as? HomeViewController {
self.home = homeVC
}
This would give us at least a better opportunity to debug. Two !s in a row maybe means you're not being totally respectful of what those declarations are trying to tell you.
The cause of this error was actually coming from a bug in xcode 6 rather than any kind of syntax error. It was related to this: Xcode 6 Strange Bug: Unknown class in Interface Builder file
I was able to fix this by clearing the projects derived data and build and restarting my machine.
I had faced the same problem while doing an unwind segue and trying to downcast the sourceviewcontroller. I bang my head for more than 30mins and then I realized it was fairly simple and bit crazy, I had all my files except this viewcontroller added to the Tests target and after adding this viewcontroller to the Tests target, everything worked Tada!! I m saved.
Related
Does anybody know why the ZoomingPDFViewer Apple Sample Code project no longer works? It was working prior to the iOS 10 release but now it keeps returning a unrecognized selector error when calling [PDFScrollView setPDFPage:].
It seems like the custom classes set in the storyboard are no longer being instantiated.
I had the same issue. It seems that the auto conversion to Swift 3 doesn't work well with IBs.
There are two options:
a) You can set the argument label--i.e.the parameter name to be shown externally--to _. For example,
#IBAction func setPDFPage(_ sender: AnyObject) {
// ...
}
b) You can remove the IBAction connection in the IB and re-set it. Notice instead of the previous setPDFPage(sender:) the connection will say setPDFPageWithSender(sender:) or something like that. (I didn't actually try it with the code in question, but writing from experience here.)
The same is true for segues.
The new entity() method helps us avoid magic strings. Rather than saying something like managedObjectModel.entitiesByName["foo"], we can say Foo.entity().
The problem is that in my testing it always throws EXC_BAD_ACCESS. I've configured my NSPersistentStore and I've run a test query to make sure that everything is set up properly.
Any insight? What are the prerequisites to call this method?
Something is wrong with your setup.
To check, open Xcode, start a new project, choose "Master/Detail", check "Core Data". In the MasterViewController, insert this line anywhere:
print("The entity is ", Event.entity(), ".")
You will see that it works out of the box. Notice that in the model editor, when inspecting the Event entity, the option "Codegen" is set to "Class Definition".
The problem turned out to be that merely initializing NSPersistentStore and calling loadPersistentStores isn't enough. You have to explicitly or implicitly use its managedObjectModel property at least once, most likely due to lazy loading.
I tentatively regard this as a bug. The entity() method should probably do this itself under the hood, though there may be other considerations.
I'm doing this tutorial (http://www.raywenderlich.com/1845/how-to-create-a-simple-iphone-app-tutorial-part-2) to get the hang of ios development, but now I'm stuck.
It's probably just a little thing, but when I get in my detailView's method 'setDetailItem', the newDetailItem variable is empty (see screenshot).
I have no idea why this is, but in the tutorial this seems to get automatically filled.
Why is it empty and how do I get the right detailItem?
I checked the tutorial and a sample code is provided by them.It works fine with the memory.It is a setter method which is called when you provide the value like this
DetailViewController *detailController =segue.destinationViewController;
ScaryBugDoc *bug = [self.bugs objectAtIndex:self.tableView.indexPathForSelectedRow.row];
detailController.detailItem = bug;
check weather you are passing in valid memory value (here bug).if you give it nil then yeah there may be no memory
I'm on this step of the "Your First iOS Application" tutorial from Apple.
However, the line [self setMyViewController:aViewController]; has an error and the app appears as a blank black screen. The error message is 'HelloWorldAppDelegate' may not respond to '-setMyViewController' (2)
I've been following the tutorial carefully. How can I make this error go away? Why is it so ambiguous (it "may" not respond? under what circumstances will it?) and why am I getting this error in the first place? What step did I miss?
Go to your header-file and add - (void)setMyViewController:(UIViewController *)viewController;
Maybe you need to rename the parameter.
And btw. it's a warning not an error. Warnings are just for signalize that it could have problems if you haven't included the method.
If you declare a method in your .h file, the .m file gives out a warning if it isn't included. Don't worry it's not wrong if you forgot to declare a method in your .h file.
Are you running your code right after following that step? You should hold off doing so until you have finished following all steps on the page.
The Housekeeping section lists a step that you have to follow in order to make your property setter work:
In the #implementation block of the class, tell the compiler to synthesize the accessor methods for the view controller:
#synthesize myViewController;
After you finish adding the code as described by that section, running your code should work. If not, check your imports and your HelloWorldAppDelegate.h file — you may have missed something else too like declaring your #property.
Why is it so ambiguous (it "may" not respond? under what circumstances will it?)
It will respond if the compiler can find an implementation of the method, and the method is declared in the header file (unless it's a property accessor), and work as normal. If it does not, your program crashes.
and why am I getting this error in the first place?
You typically get that warning (it's not an error) if the property is not synthesized. By synthesizing it, the compiler creates the myViewController and setMyViewController: accessor methods in order for your code to access that property.
That should be a warning not an error.
Take heed of warnings, and you're right to want to eliminate them, but the code will compile and may run with warnings.
The warning could be occurring because there isn't a prototype for the method setMyViewController before it is referenced. The prototype is usually defined in the associated header '.h' file.
The prototype looks like the entry line of the method, up to, but not including the first '{', and with a ';' on the end.
Adding a prototype allows the compiler to verify you're calling the method correctly (and just as importantly, you typed it correctly ;-)
I'm working on an existing, large-ish codebase, and after upgrading the iOS SDK to 4.1 I am now seeing very strange behaviour. The crux of the matter appears to be a particular class that will no longer alloc - it is throwing a bad access in obj_msgSend, and seems to be the Class object on the stack that objc_msgSend doesn't like - although it is not actually NULL.
The original failing line looked like this:-
tileProjection = [[RMFractalTileProjection alloc] initFromProjection:proj tileSideLength:sideLength maxZoom:18];
I deconstructed this to isolate the problem:-
RMFractalTileProjection *p = [RMFractalTileProjection alloc]; // <- this crashes
p = [p initFromProjection:proj tileSideLength:sideLength maxZoom:18];
tileProjection = p;
I then tried this:-
Class c = NSClassFromString(#"RMFractalTileProjection");
assert(c);
NSLog( #"RMFractalTileProjection class(ptr) %p", c ); // <- prints an address OK
NSLog( #"RMFractalTileProjection class(obj) %#", c ); // <- crashes
In the debugger it looks like the Class object is sensible, but NSLog crashes when it tries to print it.
One thing to note: the class in question is declared as below, and I'm not sure if the protocol is causing a problem. Because this particular part is a large chunk of open source code, it is very difficult to remove this protocol requirement to see if that makes a difference.
#interface RMFractalTileProjection : NSObject<RMMercatorToTileProjection>
{
...
}
Any help on this one greatly appreciated - it is a show stopper.
Thanks
This is not really an answer but some ideas to move forward.
The only causes that leap to mind at the moment are memory corruption and some sort of link issue. Perhaps you are linking two versions of the class somehow.
Assuming this is the class, there doesn't look to be anything wrong to make it crash in alloc. There's no +initialize or anything.
Questions I would be asking myself and trying to answer are:
what happens if I rename the class?
what happens if I create a new identical class with a different name?
the pointer that gets passed to obj_msgSend: is it reasonable? does it point to something that looks like a class?
do you ever subclass the class and do you use initialize on the subclass?
is the pointer always the same? If so you can watch what it points to and see if it changes during execution.
what happens if you send self to the class?
OK, finally found this. As Jeremy suggested, this turned out to be a regular memory stomper.
The difficulty I had finding it was that it wasn't the Class object itself that was getting stomped, but the class' metaclass structure - which is a normal Class object but one level up, referenced by the class 'isa' pointer. That's why the class looked OK to me when I inspected it in the debugger - I need to follow the isa pointer and dump memory at one level up to find this. Luckily for me, the class was only a subclass of NSObject - had it been deeply subclassed, this could have been much harder to find. I got my first clue after biting the bullet, reverse-engineering objc_msgSend, working out exactly what was on the stack frame, and following all the pointers. Yep, the hard way :)
Matt Gallaghar's post (and various others I found by following links) were invaluable in helping me through this maze - thanks guys!
Burned a lot of time on this one, but on the up side I learned a hell of a lot about Objective C internals during the past day and a half :)
Thanks for these suggestions JeremyP - it is always good to have fresh suggestions after you've been banging your head against the keyboard all day!
Your suggestion of creating an identical class with the same name appears to have fixed the problem. I have no idea why and I feel I need to understand what's going on here. You're right it sounds like some kind of linker issue, but I still have no idea what could cause such a serious runtime error and not even produce a warning at build time.
Re. the pointer, it does look reasonable, but something inside the class eventually gets dereferenced as a null pointer inside objc_msgSend. Occasionally, after I have changed the code and rebuilt, I get a null pointer instead. This behaviour obviously suggests something nondeterministic like a memory stomp.
I'll post my findings.