I have a C function heightParameter that is a simple tool that I use in a couple of my UIViewControllers. I am declaring this only in my main implementation of each UIViewController subclass (in the .m) above my other functions, so that I didn't even have to declare it in the header.
For some reason, I'm getting duplicate symbols in every other subclass that I use it in, despite it being implemented privately. It is within the main #implementation #end block for each subclass and shouldn't be seen by anything else, so how is it being seen globally?
C function names have global scope. Mark it static or make it a method if you want it to be restricted.
Related
I know the question is a bit generic but I guess my issue is generic as well.
I'm developing a small application in my free time and I decided to do it with Cocoa. It's nice, many things works almost automagically, but sometimes it's quite hard to understand how the framework works.
Lately I'm facing a new problem. I want to manage all the windows of the application from a single class, a front controller basically. I have a main menu and an "Import data" function. When I click it I want to show another window containing a table and call a method for updating the data. The problem is that this method is inside the class that implements the NSTableViewDataSource protocol.
How can I have a reference to that class? And more important, which should be the right way to do it? Should I extend the NSWindow class so that I can receive an Instance of NSWindow that can control the window containing the table (and then call the method)?
I may find several ways to overcome this issue, but I'd like to know which one is the best practice to use with cocoa.
PS: I know that there are tons of documentations files, but I need 2 lives to do everything I'd like to, so I thought I may use some help asking here :)
The problem is that this method is inside the class that implements the NSTableViewDataSource protocol.
How can I have a reference to that class?
These two sentences don't make sense, but I think I understand what you're getting at.
Instead of subclassing NSWindow, put your import window's controlling logic – including your NSTableViewDataSource methods – into a controller class. If the controller corresponds to a window, you can subclass NSWindowController, though you don't have to.
You can implement -importData: as an IBAction in your application delegate, then connect the menu item's selector to importData: on First Responder. That method should instantiate the import window controller and load the window from a nib.
In your import window controller's -awakeFromNib or -windowDidLoad method, call the method which updates the data.
Added:
Here's the pattern I'd suggest using in your app delegate:
#property (retain) ImportWindowController *importWC;
- (IBAction) showImportWindow:(id) sender {
if (!self.importWC)
self.importWC =
[[ImportWindowController alloc] initWithWindowNibName:#"ImportWindow"];
[self.importWC refreshData];
[self.importWC.window makeKeyAndOrderFront:sender];
}
When I use bindings I don't need to include the IBOutlet macro.
Ex.
#property NSString* stringToBind
Why is this?
When do we use the IBOutlet macro and when do we leave it out? I am confused because I thought we include the IBOutlet macro to when we want to use it as an object with interface builder.
What would happen if linked to an object (like would would normally do with an outlet) but excluded the IBOutlet macro? In other words created an outlet without the IBOutlet macro? It is optional in all cases? Is it just used to make things easier, so that they are detected?
Thanks in advance
As far as the compiler and linked are concerned, IBOutlet is a no-op. More specifically it is #define'd to nothing. Xcode and Interface Builder use static code analysis to figure out what to do, but it will have no impact on compiling or linking.
The NIB that is generated contains the names of the properties to connect when it is loaded and those names are resolved the same way that all other properties are resolved.
If you remove IBOutlet from a property declaration introduces a risk that the next time the NIB is generated, the link connection won't be made. I am not sure how Interface Builder handles that.
I saw a similar question addressing differences of the code completion between Xcode 3.2 and Xcode 4. My question addresses a specific behaviour of Xcode (3.2).
When I declare "private" methods in a class extension, these methods are visible in the code completion lists, where they shouldn't be visible.
An example (AClass.m):
#import "AClass.h"
#interface AClass()
- (void)someMethod;
#end
#implementation AClass
//...
- (void)someMethod
{
// do something here
}
//...
#end
When I import AClass.h to some other class and create an AClass-instance...
AClass *test = [[AClass alloc] init];
Xcode's code-completion shows the "private" method "someMethod":
[test som // Shows someMethod, though it shouldn't be visible here
At that point, this method is visible, even if it shouldn't be, because it's unknown here - it's not defined in the header-file. If I send the message [test someMethod] at that point and build the thing, I get a warning, that the object might not respond - as expected.
It actually does respond, but this is confusing behaviour, especially for someone else, who wants to use my class.
That affects #property / #synthesize as well, since they "just substitute methods". I want to access all of my private ivars by properties for a) having homogene code while b) being able to influence the use of ivars (like lazy instantiation). On the other hand all private stuff shouldn't be visible (in code completion) to anyone using my classes, to make it easier to use them.
Is there any way to change this behaviour?
Is the missing validation of context in Xcode 3.2 the reason, why code-completion shows this kind of methods, where they shouldn't be visible?
Is that behaviour different in Xcode 4 (because of context-validation)?
I still use Xcode 3.2, because I wanted to finish a project before switching and adapting myself to Xcode 4.
I've added a custom subclass of NSWindowController to my Cocoa project, and added an instance of my subclass to my application's nib. I expected to see my override of the -initWithCoder: method called when the nib was loaded, but it was not. To debug, I added a regular -init method and set a breakpoint on it — and sure enough I hit the breakpoint while loading the nib.
This could actually make some things simpler for me (e.g. setting the windowNibName) but I don't understand why Cocoa is behaving this way. All the documentation I have read suggests that -initWithCoder: is where I should be overriding. Why is this case any different?
I'm assuming that to instantiate your window controller in Interface Builder, you dragged a generic NSObject instance to the nib file, then assigned your custom NSWindowController subclass as the object's class, is that correct? If so, then I think they key difference going on here is that you're dealing with instantiating a generic object rather than a custom object included in one of IB's palettes.
Most of the time, when you create and configure an object using IB, the settings that you specify in the various inspectors gets encoded using the encodeWithCoder: method when the nib file gets saved. When you then load that nib file in your application, those objects get initialized using the initWithCoder: method.
However, in the case of that generic object instance, Interface Builder doesn't necessarily know anything about the class of the object being instantiated. Since you can specify any class name at all to be instantiated, if you specify a class that IB doesn't have loaded via a palette or framework, there's no way it can serialize that object using NSCoding. So I believe that when you instantiate a generic object like that, it gets initialized using init rather than initWithCoder: because it wasn't saved using encodeWithCoder: in the first place when the nib file was saved.
I don't know if this is documented anywhere, but I think that's why you're seeing a difference there. I also don't think it's specific to NSWindowController, but rather you'd see the same behavior from any object instantiated as a generic NSObject in IB, regardless of the specific class.
I still don't have a formal answer why Cocoa behaves this way, but in practical use it seems to be convenient. I have defined an NSWindowController subclass with the following -init method and it works like a charm.
- (id)init;
{
if ((self = [super initWithWindowNibName:#"MumbleMumbleSheet"]) != nil) {
…
}
return self;
}
If -initWithCoder: were being called I would have to figure out how to fulfill the implicit obligation to call the super -initWithCoder: method and still get the right -windowNibName used for loading. It's much more straightforward this way.
I would still appreciate a pointer to some documentation that says this class is different and explains why and how… But in the absence of documentation there is empirical evidence.
The coder methods are used for classes that have been serialised and saved to file.
What you are doing here is different. You are building your controller class into your executable. This means that there's no need to read the class itself from file as it's a part of the running application binary.
When using this controller class you need provide an init method where you provide the nib file name. Why? Well, you have the compiled class as a part of your exe but no knowledge about what the nib file is. This is how you provide that knowledge.
Think of it this way. You controller class is a part of the exe. Some link between it and the nib file needs to be made. One way would be to scan through all the nib files looking for references to this controller. That would be inefficient. Provide the name in the init and everything bootstraps.
In other words you have learnt some important lessons from your experiments. Well done, on being so observive.
When a Cocoa NIB file instantiates an instance of a custom controller object, what is the name of the variable that that custom controller instance is assigned to?
In case that isn't clear, if you manually created an instance of that class you would do:
MyControllerClass *myVar = [[MyControllerClass alloc] init];
What equivalent of "myVar" has the NIB used when doing this behind the scenes?
There is no such thing as a variable name once the app is compiled, so this question doesn't make much sense. In your example, myVar is just a convenient label for you, the programmer, and does not exist in any way once your source code is compiled into binary code.
When you place an object into a nib file, it is archived and then unarchived at runtime. If you want to be able to get a reference to an object that has been archived in a nib file, you need to use an outlet, which means you declare an IBOutlet instance variable in a class that is present in the nib file and then connect that outlet to the object in the nib you want to reference in Interface Builder. Instance variables are different to the stack variable that you declared in your example and can be referred to at runtime.
Typically you would have an object that "owns" a nib. Normally nibs are loaded by an instance of NSWindowController or NSViewController and window or view controller is represented in the nib file as File's Owner. If you declare outlets in your window/view controller, you can then connect the outlets from File's Owner to your object in Interface Builder.
So, to clarify, you need a reference to your object in the nib from some other object in the same nib. That second object declares an outlet using the IBOutlet keyword on an instance variable like so:
#interface SomeOtherObject : NSObject
{
IBOutlet SomeObject* anObject;
}
#end
In Interface Builder, you can then connect the anObject outlet of the SomeOtherObject instance to the first SomeObject instance. You can do this by control-dragging from one object to another or you can do it in the connections panel in the Interface Builder inspector.
You can then refer to your SomeObject instance by the variable name anObject inside the code for SomeOtherObject.
Implement the awakeFromNib method in your controller class - it's called immediately after the nib has finished loading, and your controller's instance can be found in the "self" variable.
# tedge (I can't make comments to your answer):
Can you clarify for a beginning Cocoa learner a bit. Take the Apple Currency Converter tutorial.
I implement the awakeFromNib method in the existing ConverterController class. (Something I will be learning to do shortly!)
The app starts up and an instance of ConverterController is automatically instantiated.
What will awakeFromNib tell me about that running instance (other than that it's ready to use) -- and what syntax with "self" gets it to divulge that information?
… what is the name of the variable that that custom controller instance is assigned to?
It's whatever name you gave that variable when you declared it.
IB doesn't create variables for you. It sounds like you're after an outlet, which is a variable you create that IB knows about and lets you plug objects into, thereby setting the variable.
(You actually can create outlets from IB, and in the modern runtime, this should really create the outlet, not just declare a non-existent outlet in the nib. Even this way, though, you create the outlet [in IB] and you give it a name.)
I think what's Nibbles is confused about is that how to reference the variable defined only in NIB file from code.
the answer to that is, normally you have a custom controller class (or delegate class) A in code and NIB, and if you have another class or controller B only defined in NIB, just setup a outlet in A pointing to B. Since A can be used anywhere in your code, B can be accessed as well through A then.
I had this question as well.