Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

moonman239

Cancelled
Original poster
Mar 27, 2009
1,541
32
I have a setter method that is supposed to be called. I set two breakpoints, one on the line in which the setter method is supposed to be called, and the other on a line in the setter method itself. The first breakpoint activated, but the second did not. I can't figure out why the second one wasn't called, because the little tag is dark blue, the breakpoint is not inside an "if" block, and there are no conditions.
 
Without seeing the actual code, the likelihood of receiving useful help on its operation is sharply reduced.

Also consider posting a screenshot showing the breakpoints and the code. You could be missing something, which would mean it's not present in your description, despite your best intention of providing enough information for others to assist you.

Debugging from descriptions alone is nearly impossible. If all you're doing is rubber duck debugging, you'd annoy fewer people and probably get equal results by getting and using an actual rubber duck. Or even a picture of one.

Since we're discussing debugging techniques, another one to try is "Make a simple test case illustrating the problem". If the test case ends up showing the problem, post its code and it will adequately illustrate the problem. If the test case ends up NOT showing the problem, then you need to look very carefully at the differences between the test case, which doesn't show the problem, and the actual problem case, which does.
 
Without seeing the actual code, the likelihood of receiving useful help on its operation is sharply reduced.

Also consider posting a screenshot showing the breakpoints and the code. You could be missing something, which would mean it's not present in your description, despite your best intention of providing enough information for others to assist you.

Debugging from descriptions alone is nearly impossible. If all you're doing is rubber duck debugging, you'd annoy fewer people and probably get equal results by getting and using an actual rubber duck. Or even a picture of one.

Since we're discussing debugging techniques, another one to try is "Make a simple test case illustrating the problem". If the test case ends up showing the problem, post its code and it will adequately illustrate the problem. If the test case ends up NOT showing the problem, then you need to look very carefully at the differences between the test case, which doesn't show the problem, and the actual problem case, which does.


Thanks for helping me receive some debugging advice!

Anyways, I realize that it's generally good etiquette to post code. Sometimes, however, I feel that posting my code will only cause someone else to come to the same conclusion that I originally came to.

UPDATE: The app appears to use a setter method to set the property, but not the one I created.
 
Last edited:
Thanks for helping me receive some debugging advice!

Anyways, I realize that it's generally good etiquette to post code. Sometimes, however, I feel that posting my code will only cause someone else to come to the same conclusion that I originally came to.

Then let someone else reach that conclusion independently. The only way to do that is with the code you wrote.

If you're doing something wrong and not seeing it, then no one can possibly diagnose the problem without seeing the code you actually wrote. That's because the problem lies in your perception of the code, which is the very thing you're relying on to tell you that someone else will come to the same conclusion. In other words, you may be relying on mistaken perception to reach your conclusion. You can't see the problem, because you literally can't see the problem.

It's not just etiquette, it's trying to actually solve the problem. When no one but you can see the code, then everyone has to rely on your perception and judgement of what the code actually does, i.e. your description. But if that perception or judgement is mistaken or incomplete, then literally no one at all can solve the problem. You can't, because you can't see the problem. Others can't, because they can't see the code. Result: problem is insoluble (except by chance).

UPDATE: The app appears to use a setter method to set the property, but not the one I created.
The property name is what?

The setter method's name you created is what?

The class is descended from what other class?

Be specific and use the actual names; copy and paste verbatim, don't paraphrase, obfuscate, or edit in any way.
 
Then let someone else reach that conclusion independently. The only way to do that is with the code you wrote.

If you're doing something wrong and not seeing it, then no one can possibly diagnose the problem without seeing the code you actually wrote. That's because the problem lies in your perception of the code, which is the very thing you're relying on to tell you that someone else will come to the same conclusion. In other words, you may be relying on mistaken perception to reach your conclusion. You can't see the problem, because you literally can't see the problem.

It's not just etiquette, it's trying to actually solve the problem. When no one but you can see the code, then everyone has to rely on your perception and judgement of what the code actually does, i.e. your description. But if that perception or judgement is mistaken or incomplete, then literally no one at all can solve the problem. You can't, because you can't see the problem. Others can't, because they can't see the code. Result: problem is insoluble (except by chance).


The property name is what?

The setter method's name you created is what?

The class is descended from what other class?

Be specific and use the actual names; copy and paste verbatim, don't paraphrase, obfuscate, or edit in any way.

Off topic question but your response made me think about something I had been thinking about recently. How important is "inheritance" when writing Objective-C applications? Is it something that I should be doing in pretty much all my apps, or only ones that do specific types of tasks? I feel like the apps I've written haven't had a need to use it, besides Apple provided ones (e.g. NSObject, UITableViewController, etc...). When I went through the Big Nerd Ranch book I completed the exercise for it, but haven't actually used it in real practice yet.

Is it something I should be doing? It may be because I don't fully understand it, but I think I do.

E.g.

Class Console - Inherits from NSObject
Class Nintendo Console - Inherits from Console
Class Sega Console - Inherits from Console


(I didn't go to school for CS, just something that interests me)
 
Inheritance is something you use when it makes sense to do so.

Using your example:
Class Console - Inherits from NSObject
Class Nintendo Console - Inherits from Console
Class Sega Console - Inherits from Console
You first have to decide what Console does, and what it will have for methods and properties. If something is common to all subclasses, then put it in Console and inherit it. If something isn't common, then don't put it in Console. I have no clear idea what you intend these classes to do, so I can't offer specific suggestions about inheritance.

A better example might be NSArray and its mutable subclass NSMutableArray. Or any other pair of immutable class and mutable subclass, such as NSData, NSString, etc. and their mutable counterparts.

The design relationship is pretty clear: a mutable NSMutableArray should be capable of everything its immutable superclass can do, plus the mutable subclass should be mutable. Since this is the clear intended relationship, it simply makes sense to use inheritance.

Thinking it through is the essence of software design. If using a feature makes sense for the design, use it. If it doesn't make sense, don't use it.

In my experience, having a clear design before starting to assign classes and inheritance will make the classes and their relationships clear. They should grow out of the design, not be pushed into the design.

Without a clear design, you get incomprehensible parts stitched together like a crazed combination of grain sack, circus tent, sailboat sail, and ballroom gown, where the only commonality is they're made of fabric and they have seams.
 
Inheritance is something you use when it makes sense to do so.

Using your example:
Class Console - Inherits from NSObject
Class Nintendo Console - Inherits from Console
Class Sega Console - Inherits from Console
You first have to decide what Console does, and what it will have for methods and properties. If something is common to all subclasses, then put it in Console and inherit it. If something isn't common, then don't put it in Console. I have no clear idea what you intend these classes to do, so I can't offer specific suggestions about inheritance.

A better example might be NSArray and its mutable subclass NSMutableArray. Or any other pair of immutable class and mutable subclass, such as NSData, NSString, etc. and their mutable counterparts.

The design relationship is pretty clear: a mutable NSMutableArray should be capable of everything its immutable superclass can do, plus the mutable subclass should be mutable. Since this is the clear intended relationship, it simply makes sense to use inheritance.

Thinking it through is the essence of software design. If using a feature makes sense for the design, use it. If it doesn't make sense, don't use it.

In my experience, having a clear design before starting to assign classes and inheritance will make the classes and their relationships clear. They should grow out of the design, not be pushed into the design.

Without a clear design, you get incomprehensible parts stitched together like a crazed combination of grain sack, circus tent, sailboat sail, and ballroom gown, where the only commonality is they're made of fabric and they have seams.

Thanks for the explanation! My example wasn't actually part of anything just something I tried to throw together as a quick example.
 
Dependency analysis warning

I just looked at the warnings Xcode threw, and came across one that might help me resolve this problem.

The warning says, "no rule to process file '/Users/montana/Documents/Xcode Projects/app/app/appVC.h' of type sourcecode.c.h for architecture i386"

I checked my dependencies and under "Compile Sources." There are no listed dependencies, and the header file is listed under "Compile Sources."

Edit: I should add that that is true for the first listed target; the other one lists 1 dependency - my app - and 1 source - a .m file whose name contains "Tests."
 
Last edited:
I just looked at the warnings Xcode threw, and came across one that might help me resolve this problem.

The warning says, "no rule to process file '/Users/montana/Documents/Xcode Projects/app/app/appVC.h' of type sourcecode.c.h for architecture i386"

I checked my dependencies and under "Compile Sources." There are no listed dependencies, and the header file is listed under "Compile Sources."

Edit: I should add that that is true for the first listed target; the other one lists 1 dependency - my app - and 1 source - a .m file whose name contains "Tests."

moonman, you still haven't shared any useful information with us. I remember that there was somebody complaining on MR's forums that everything they post on Stack Overflow gets closed - was that you? Because I wish I could close and delete this topic as I would on SO. This question can not be answered until you actually share your code.
 
moonman, you still haven't shared any useful information with us. I remember that there was somebody complaining on MR's forums that everything they post on Stack Overflow gets closed - was that you? Because I wish I could close and delete this topic as I would on SO. This question can not be answered until you actually share your code.

OK, here's more info:

I have a view controller that we'll call Alice. Alice initiated a segue to Bob, another view controller. In Alice's prepareForSegue method, Alice sets one of Bob's properties to one of her properties. However, it seems that Bob's viewDidAppear method is invoked before the simulator realizes that Alice passed an object to Bob. Later on, though, the simulator seems to acknowledge that the aforementioned property does, in fact, exist.

By the way, Bob's class's .m file has a synthesize statement for the property.


Bob is an instance of the class whose header file seems to cause the above warning.
 
OK, here's more info:

I have a view controller that we'll call Alice. Alice initiated a segue to Bob, another view controller. In Alice's prepareForSegue method, Alice sets one of Bob's properties to one of her properties. However, it seems that Bob's viewDidAppear method is invoked before the simulator realizes that Alice passed an object to Bob. Later on, though, the simulator seems to acknowledge that the aforementioned property does, in fact, exist.

By the way, Bob's class's .m file has a synthesize statement for the property.


Bob is an instance of the class whose header file seems to cause the above warning.

This is essentially useless. All it does is describe what you think is happening, for the reasons you think are causing it.

If you were to turn the above description into actual code, as a simplified test case, then actually compile and run it, and it actually showed the problem, then it would be useful. Because then you could post the code for the test case, and we could see it in action on our own machines by compiling and running it. When you've done that, someone might be able to help you.

As it now stands, all you've done is write another description, whose accuracy in terms of corresponding to actual code is undetermined.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.