XCode Error, unable to see a difference - objective-c

Alright, I'm reading the Aaron Hillegass book for Cocoa Programming, on the drag and drop chapter. I was following along with one of the lessons, and I typically change variable names as I find it keeps me a little more engaged and gives me a better understanding. I started getting this error, though:
2010-10-04 00:38:06.699 TypingTutor[421:a0f] -[BigLetterView dragImage:at:offset:event:pasteboard:source:slideback:]: unrecognized selector sent to instance 0x100424390
Now, I figured it was because I'd messed up some variable name so I went back and copied the variables directly from the book and still got the error. XCode was saying the following function might not get a response. Well, regardless I could not figure it out for the life of me, so I scrapped the function and redid it. What drives me crazy is that it worked the second time, but I did notice a difference in that XCode highlighted the syntax of the function that works, but didn't for the one that doesn't. I can see no physical difference and am stumped as to why one is different than the other. Both were typed in on a Mac keyboard, so I can't see it being some hidden character due to encoding, but yeah, I'm just hoping I'm missing something extremely obvious because it's 1 AM... has anyone ever run into this before?
Methods copied directly from .m file...
This one works
[self dragImage:anImage
at:p
offset:NSMakeSize(0,0)
event:mouseDownEvent
pasteboard:pb
source:self
slideBack:YES];
This one doesn't
[self dragImage:anImage
at:p
offset:NSMakeSize(0,0)
event:mouseDownEvent
pasteboard:pb
source:self
slideback:YES];

Objective-C is case sensitive, so method names with different cases in their letters are considered different methods. The one that works, "slideback" is written slideBack with a capital B, which is probably what you're calling. The one that doesn't has a lowercase 'b' and is written slideback. In Objective-C, those are different methods. The definition is obviously written with the uppercase 'B', which is why that one works and the other doesn't.

Related

Category method not always called when app runs under Mavericks

I have an app that I sell in the Mac marketplace and this app has been running without a hitch -- until customers started running it under Mavericks.
What it boils down to are exceptions like this that I'm getting back from customers:
11/7/13 8:54:17.841 AM MyApp[65256]: -[Property watts Per Square MeterStringValue]: unrecognized selector sent to instance 0x7fa66c80a760
Now, it's obvious that "watts Per Square MeterStringValue" is not a valid selector, but let me explain.
I have a category on NSString that has a series of methods which do different things like remove spaces from strings, or set the first character of a string to lowercase, etc. This category exists in a framework that I embed in my app.
One particular method in that category is "bindString" which converts a string to a bindable, camel case string. So:
[#"This is a Funky String" bindString]
would yield:
"thisIsAFunkyString"
What appears to be happening in my app under Mavericks is that the category method is not being always called, even though it is referenced in the source. This behavior is purely random. While the app is running, sometimes it will be called, and sometimes not. When it's not, exceptions like the one above occur.
This happens ONLY under Mavericks. The same binary works flawlessly under Mountain Lion and Lion.
Now I'm wondering why this is. Is it an Obj-C runtime issue under Mavericks? Is it an Xcode 5.0.1 compiler issue? I don't know, but it's just plain weird, and it's driving me up the wall.
I've tried just about everything. The next thing I'm going to try is to yank the category .m and .h out of the framework and put it directly into the app project.
Has anyone seen anything like this under Mavericks?
Hanging categories off NSString is generally a bad idea. Especially when your method names aren't prefixed. If you really have a method named bindString in a category on NSString, you may be colliding with a method provided in a category somewhere in the Apple frameworks. When two categories implement the same selector, which one "wins" is indeterminate.
Keep in mind that NSString is a class cluster. Thus, if the method is colliding with a method on a subclass, you'll also see weird behavior in that your category's method may not always be invoked.
At the very least, put a prefix on all of the methods in categories on system classes. Better yet, don't extend the system classes; put your methods in their own class.

How to debug an incorrect binding

I got the error cannot create BOOL from object with CoreData. I read a lot of questions on this, all leading to the same conclusion: an incorrect binding in IB.
Is there a way I could for example list all bindings, or is there a utility app that checks the type of the bindings? Perhaps catch the error, or implement a method that gets called when this happens so I can retrieve the name of the bound object? I'd rather solve it myself than have someone nice analyse my .xib.
I've been pulling my hair out over this. In a XIB with dozens or potentially hundreds of bindings it's almost impossible to find out where this is coming from. But I finally found a way to narrow it down a bit.
I just set a symbolic break point on
-[NSValueBinder _observeValueForKeyPath:ofObject:context]
and configure it as follows
Action: Debugger Command, Enter po $rdi as the command to execute. This will print out self (i.e. the NSValueBinder description) every time the break point is hit. This ($rdi) is for x86_64, for other architectures see this article.
Check Automatically continue after evaluating
Now when I run the program I get a bunch of binding related logs in the console that should look something like this:
$7 = 4301564448 <NSTextValueBinder: 0x10064aa20>{object: <NSTextFieldCell: 0x10061eea0>, bindings: value=selection.myProperty}
The last one is obviously the one that throws the exception. I can usually figure out which view it is from the bindings value directly or from some of the other bindings that are established before the error occurs. Another thing that helps, is examining the superview or controlView of the offending object, e.g. with po [0x10061eea0 controlView] in the example above.

Reset/fix Xcode 4.5 code completion

One of the new "features" in Xcode 4.5 was supposed to be vastly improved code completion. It was supposed to learn what you type regularly and provide these more frequently as options for code completion.
However, for me this isn't working at all.
One of the famously bad code completion words is NSString.
When I type it I get...
NS - NSAddedPersistentStoresKey
NSS - NSSaveChangesRequest
NSSt - NSStoreModelVersionHashesKey
NSStr - NSStream
NSStri - NSStrikethroughStyleAttributeName
NSStrin - NSString
I have never used any of the other suggestions given and most of them I'm not actually sure what they are. I use NSString many times a day, why wasn't it suggested first? In fact, apart from NSSet I don't think I've ever used another class that begins with NSS.
Also, when looking for NSLog() which used to get suggested when I typed NSL I now get...
NS - NSAddedPersistentStoresKey
NSL - NSLayoutAttribute
NSLo - NSLoadedClasses
NSLog - NSLog(<#id, ...#>)
Again, never heard of the others.
Is there any way to fix this so that I get the functionality that Apple says I should be getting?
Thanks for any help.
OK, I deleted the UserInfo folder from ~/Library/Developer/Xcode/ and it seems to have fixed it.

No visible #interface for

I have gotten this error on several occasions and am unclear as to what causes the error in general. After looking for over an hour on stack overflow and google I still don't have an answer. Could someone help?
I've seen several specific answers but nothing that says why the error happens, only "do x", or "do y".
I haven't included code yet because I want to know the reason that this error happens in general so I can fix my code in the future whenever I get this error.
There are lots of reasons it could happen, but generally it's saying that at the line of code it flags, it doesn't see any evidence that the selector you are referencing is in the interface of the type it thinks the object has.
In this example,
No visible interface error
They declared operandStack with the wrong type.
In this one
http://www.raywenderlich.com/forums/viewtopic.php?f=2&t=3312
They had a typo in the selector name
Any chance you are on Xcode 4.2 (or less), running code that was written on Xcode 4.3? In 4.3+ Xcode doesn't require you to declare private methods at all, it just assumes that methods written in the implementation file (without declarations in the interface) are private. But in Xcode <= 4.2, this will throw an error and those methods need to be at least declared privately
I just had this problem; mine was caused by me setting the method as a class method rather than an instance method. Very silly.
Another reason can be when using categories in libraries and you haven't set -ObjC (or -all_load) in the Other Linker Flags
Another common error ist to forget to write [someInstance setSomeValue:3]; instead of [someInstance someValue:3] (<- wrong). That what happened to me.
When I have run into this problem it turned out that Xcode had not reindexed files after changing Git branch. The solution is Delete Derived Data.
Using Xcode version 10.0 File -> Workspace Settings...(or Project Settings...) -> click on the little green circle and manually remove all files in DerivedData folder
I had this problem with NSSavePanel -beginSheetModalForWindow::, which obviously exists. I tried doing a clean rebuild as well as deleting the DerivedData, but no luck. I had copy-pasted and then modified, but I commented that out and typed out the call to -beginSheetModalForWindow and it started working. As far as I can tell I did not have any mistakes in the original call.

Argument values being corrupted through function calls in Objective-C

So I seem to have a sporadic problem, that no amount of Google-fu has thus far been able to solve. At seemingly random points functions will just break, and after some hunting it appears arguments will begin to get corrupted.
For example
Object * testObject = [[Object alloc] init];
NSLog(#"ID: %d", testObject);
[testFunction:testObject];
...
- (void) testFunction:(id)testObject
{
NSLog(#"ID: %d", testObject);
When this happens the Log statements in this case would fail to match up, giving me EXC_BAD_ACCESS warnings or other various issues when I go to use the reference I passed.
Sometimes I can fix the issue by tacking on a 'Dummy value' to the function like so:
- (void) testFunction:(id)testObject:(int)dummy
{
and then calling it like so:
[testFunction:testObject:1111];
My function declarations all match in the .h/.m files, the only thing I could guess is that potentially elsewhere in the project there might be missing corresponding function declarations in .h files. However the functions in question are always done correctly. (I have double, triple checked etc). I know it's not a retain/release issue, while I am relatively new to Objective-C I have that down pat and I have also ran it through Instruments looking for leaks and there appear to be none. Any thoughts as to what might cause this, and why issues pop up after changing seemingly completely unrelated code elsewhere in the project?
Your problem is probably that you are logging your objects in the wrong way.
When you log an Object you can't just format it like you did.
When you log any code you need to format it precisely right you will get bad access errors.
You should really read up on the apple documentation about the right formats.
And you can do this here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html