I have a nib file I want to open up, but it is just an info panel so I dont need any methods for it. Is there a way I can just open it. I am not in a class that is a subclass of NSWindowController.
Yes, you can make any object the owner of a xib. That object, however, has to "host" the outlets used in your xib.
For example, if you have a "ConfirmationSheet.xib", just declare your outlets in the class you want to "own" that instance of the xib, set the File's Owner class to your class, then connect your outlets. Let's use an outlet named "confirmHowMuchSlider" as an example: when the xib is loaded, your class's "confirmHowMuchSlider" outlet will be connected to the slider you connected in the xib and that's that.
Note this generally a sign of not-so-good design, IMO. If it's complicated enough to be in its own xib, it should have its own controller. If it's not complicated (just a sheet), you can sacrifice another 0.001 seconds of app or document load time and put it in a more central xib. :-)
Remember, if you are doing this for performance reasons, a separate round of disk access just to load a single sheet with a few buttons is generally worse in performance than loading more stuff in one go from one xib. All things are a tradeoff.
Look at NSBundle Additions Reference.
Related
I have a subclassed NSCollectionView that is created in Interface Builder and is bound to an array.
I need to implement some of the delegate classes from NSCollectionViewDelegate but I'm kind of stumped as to what class to designate as the delegate.
Do I just create a random NSObject and designate it as the delegate? Do I create an NSViewController and designate that as the delegate—but if so, since the Collection View isn't being created programmatically, how do I tie the NSViewController to the Collection View?
Any pointer to a good document that would explain stuff like this in Mac app architectural decisions would be a great bonus.
It is common, but not mandatory, to make a view controller also be the delegate of the underlying view object. However, you can also make a new class as you suggest and use that. If that works for your overall architecture, do that.
What kind of object is the File's Owner of the NIB? Most often, a NIB should be loaded and owned by either an NSWindowController or NSViewController (or subclass of one of those). That controller would typically be responsible for everything in the NIB, so it would be the delegate.
If it makes sense, you might put the collection view into a NIB all its own. You'd create a subclass of NSViewController to load and own the NIB and set the class of the File's Owner placeholder in the NIB to that class. You'd connect the view outlet of File's Owner to the collection view and the delegate outlet of the collection view to File's Owner.
I have one NSTableView nib that contains a number of cells that will be reused throughout 3 different NSViewControllers. The NSTableView and cells function in the same way and look similar but present different data in each of the different views.
Right now I can set the File's Owner to one of the NSViewController classes, but not all of them meaning I'd have to duplicate the nib 3 times. Given that I'm loading with initWithNibName:bundle I don't see any way to set the File's Owner first either.
How can I use one nib with multiple File's Owner for NSViewControllers?
Any ideas?
Have you tried simply NSViewController or a subclass of it that is an abstract superclass of your view controllers?
One subclass could even be sufficient if the differences between your instances can be managed with conditional logic in the subclass.
Either way, it sounds like you have some refactoring to do, but minimal.
I am an iOS developer not OSX but we also face this problem. In our case I would have used a UIView class(surely you will have NSView kind of class) and then added table on that class and made File's Owner of the table to that view class.
I can reuse this class whenever I want in any view controller by adding this view on that controller and changing its data set.
I'm very new to objective-c and it seems my question is so basic there's nothing concise on it around (I just end up more confused by reading things).
When you create a .xib file, you link it to a controller (usually, I think). At the same time, you can do things you can do in .xib by defining views in code. I thought I understood part of it when I realized most of the items you drag onto a .xib are view objects. I guessed from there that .xib were somehow just representing real code for views. Is that accurate? Or am I completely wrong? I really have no idea.
Xib files do not represent real code for views, only the structure of the view's data. Each xib (or a storyboard) has enough information to do all of the following:
Instantiate elements of the view
Set properties of individual elements of the view
Connect elements of the view in a hierarchy
Connect "outlets" of objects in the Nib to properties or variables of views in your code.
However, there is no "real code" there, only the metadata. Cocoa has enough smarts to build and connect the objects, but the actual code is always in your .m files.
A view controller manages a view which is made up of many subviews. While, every view can have only one superview at most. ( superview is nil for the top-most view). This is called the view hierarchy.
The top level view in a hierarchy can be defined using pure code, or with Interface Builder, which produces a xib.
Its useful also to explore the relationship of view controllers to each other. Within one application window, there can also be several view controllers, each managing their own top-level view. This is called view-controller containment. An example of this is a UINavigationController or tab-bar controller. . .in more complex apps it is common to set up your own root controller that manages this aspect of controller heirarchies. (Eg swipe to reveal a navigation controller, which is under the main content cotroller).
A XIB describes arbitrary objects that conform to NSCoding but is usually used to layout a view hierarchy. So it'll be mostly UIViews, usually with a UIViewController.
However they're purely data. No code is generated. The system reads the XIBs and creates the objects purely as a data-reading exercise.
Objective-C has a fully reflective runtime — you can lookup classes by name as a string and can call methods on them the same way, without even knowing whether the method really exists in advance. Interface builders that secretly write code, such as Microsoft's in Visual C++, tend to do so because there's no way they could establish whatever you've described purely by parsing data.
The issue i am facing deals with multiple views, each needing to communicate with one another. I chose to use the File Owner for this, but can't seem to be able to access the already loaded instance of it from inside of views.
Each rectangle represents its own view
Activity will happen on "Some View", where user's event will cause Labels in top view to be updated
Event will not be triggers by a button click of anything like that. No outputs are set up to establish relationships between the views
No outlets are set up between the views
Outlets are setup however between top Views (with Labels) and File Owner (UIViewController).
Ultimately, i'd like to update label in view 1 from view 2.
Then the bar moves, I want labels to change
At this time, i believe a reasonable solution would be to ask the File Owner to make a change for Labels. From the "Some View", i'd like to call the File Owner and make a request.
From the stand point of the any view residing as part of the nib, how can i know who the "File Owner" of this nib is?
In the Interface Builder, File Owner maintains the IBOutlet to UILabels of the view.
You need to define a delegate (or whatever you like to call it) outlet in your Puzzle1 class and link this to File's owner in the nib. This will give you a pointer to the instance of the view controller that currently owns your view. If you set the type of the delegate to your viewcontroller subclass, then its methods and properties will be available to you from within the view.
This sounds potentially horrendously messy and is probably better solved by using NSNotifications.
But anyways, did you know there's a UINib class? Perhaps you could subclass that and keep track of the owners (which get passed in it's instantiateWithOwner: options: method) as things are loaded.
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UINib_Ref/Reference/Reference.html
I'm having an extremely difficult time trying to access information from an object (e.g. an NSTextField) that is located on a NIB other than my "MainMenu.nib".
My current setup:
I have a MainMenu.xib that contains only a toolbar at the top and an NSView. I have four other .xib files containing custom NSViews and each of their File Owner's are assigned to a NSViewController subclass which I have created for each. My MainMenu.xib contains an object that is set to my WindowController subclass that takes care of swapping the fours views into the NSView on my MainMenu.xib. All of this works fantastic.
Where I have a problem:
I have another class that acts as the brains to my application which sends and receives data from an online server, all of the methods I have created rely on inputs from the user that are located on the individual .xibs that swap into my MainMenu.xib's NSview. Unfortunately I have no idea on how to grab the information from the NSTextFields, textViews, etc. that are located on my individual .xib files.
What I've tried:
I have tried setting the File Owner's of the four individual .xibs to my "brains" class and connecting outlets defined in my "brains".h, but when I call [textField stringValue] I receive a NULL response. I'm thinking this is because I'm creating multiple instances of my "brains" class but not totally sure.
Any help on accessing information from textFields from other nibs would be a great benefit, thanks in advance.
each of their File Owner's are
assigned to a NSViewController
subclass which I have created for each
I think the easiest way (not the best way) is that your brain contains all 4 NSViewController subclass and you leak the information of the UITextField out using the property and then you can access them