Xcode provides a generic object that you use specifically when adding controllers and other non-visual objects to a nib file. It also provides the controller objects that are typically used to manage Cocoa bindings. Instead, you create this object in your code and pass it to the nib-loading code. The reason this object is so important is that it is the main link between your application code and the contents of the nib file. More specifically, it is the controller object that is responsible for the contents of the nib file.
When you load the nib file, the nib-loading code recreates these connections using the replacement object you specify. This allows your object to reference objects in the nib file and receive messages from the interface objects automatically. Menu items commonly target the First Responder placeholder. For example, the Minimize menu item in the Window menu hides the frontmost window in an application, not just a specific window, and the Copy menu item should copy the current selection, not just the selection of a single control or view.
Other objects in your application can target the First Responder as well. When you load a nib file into memory, there is nothing you have to do to manage or replace the First Responder placeholder object. For more information about the responder chain and how it is used to dispatch events in AppKit—based applications, see Event Architecture in Cocoa Event Handling Guide. For information about the responder chains and handling actions in iPhone applications, see Event Handling Guide for iOS.
When your program loads a nib file, Cocoa recreates the entire graph of objects you created in Xcode. This object graph includes all of the windows, views, controls, cells, menus, and custom objects found in the nib file.
The top-level objects are the subset of these objects that do not have a parent object. The top-level objects typically include only the windows, menu bars, and custom controller objects that you add to the nib file. If you do not use outlets, however, you can retrieve the top-level objects from the nib-loading routines directly.
You should always keep a pointer to these objects somewhere because your application is responsible for releasing them when it is done using them. For more information about the nib object behavior at load time, see Managing the Lifetimes of Objects from Nib Files.
In Xcode, you can refer to external image and sound resources from within the contents of your nib files. Some controls and views are able to display images or play sounds as part of their default configuration. The Xcode library provides access to the image and sound resources of your Xcode projects so that you can link your nib files to these resources. The nib file does not store these resources directly. Instead, it stores the name of the resource file so that the nib-loading code can find it later.
When you load a nib file that contains references to image or sound resources, the nib-loading code reads the actual image or sound file into memory and and caches it. In OS X, image and sound resources are stored in named caches so that you can access them later if needed. In iOS, only image resources are stored in named caches. When creating your nib files, it is important to think carefully about how you intend to use the objects in that file. A very simple application might be able to store all of its user interface components in a single nib file, but for most applications, it is better to distribute components across multiple nib files.
Creating smaller nib files lets you load only those portions of your interface that you need immediately. They also make it easier to debug any problems you might encounter, since there are fewer places to look for problems. Design your nib files with lazy loading in mind. Plan on loading nib files that contain only those objects you need right away.
In the main nib file for an OS X application, consider storing only the application menu bar and an optional application delegate object in the nib file. Avoid including any windows or user-interface elements that will not be used until after the application has launched.
Instead, place those resources in separate nib files and load them as needed after launch. For a window or menu that is used only occasionally, store it in a separate nib file. By storing it in a separate nib file, you load the resource into memory only if it is actually used.
When a nib file is loaded into memory, the nib-loading code takes several steps to ensure the objects in the nib file are created and initialized properly. Understanding these steps can help you write better controller code to manage your user interfaces. When you use the methods of NSNib or NSBundle to load and instantiate the objects in a nib file, the underlying nib-loading code does the following:.
The raw data for the entire nib object graph is loaded into memory but is not unarchived. Any custom image resources associated with the nib file are loaded and added to the Cocoa image cache; see About Image and Sound Resources. Any custom sound resources associated with the nib file are loaded and added to the Cocoa sound cache; see About Image and Sound Resources. It unarchives the nib object graph data and instantiates the objects.
How it initializes each new object depends on the type of the object and how it was encoded in the archive. The nib-loading code uses the following rules in order to determine which initialization method to use. In OS X, the list of standard objects includes the views, cells, menus, and view controllers that are provided by the system and available in the default Xcode library.
It also includes any third-party objects that were added to the library using a custom plug-in. Even if you change the class of such an object, Xcode encodes the standard object into the nib file and then tells the archiver to swap in your custom class when the object is unarchived. Custom views are subclasses of NSView for which Xcode does not have an available implementation. Typically, these are views that you define in your application and use to provide custom visual content.
Custom views do not include standard system views like NSSlider that are part of the default library or part of an integrated third-party plug-in. The custom view object includes the information it needs to build the real view subclass you specified. At load time, the NSCustomView object sends an alloc and initWithFrame: message to the real view class and then swaps the resulting view object in for itself.
The net effect is that the real view object handles subsequent interactions during the nib-loading process. Custom objects other than those described in the preceding steps receive an init message.
It reestablishes all connections actions, outlets, and bindings between objects in the nib file. The approach for establishing connections differs depending on the platform:. For each outlet, Cocoa looks for a method of the form set OutletName : and calls it if such a method is present.
If it cannot find such a method, Cocoa searches the object for an instance variable with the corresponding outlet name and tries to set the value directly. If the instance variable cannot be found, no connection is created. Setting an outlet also generates a key-value observing KVO notification for any registered observers. These notifications may occur before all inter-object connections are reestablished and definitely occur before any awakeFromNib methods of the objects have been called.
In iOS, the nib-loading code uses the setValue:forKey: method to reconnect each outlet. That method similarly looks for an appropriate accessor method and falls back on other means when that fails.
If the target object does not respond to the action method, no connection is created. If the target object is nil , the action is handled by the responder chain.
If the target is nil , the action is handled by the responder chain. In OS X, Cocoa uses the bind:toObject:withKeyPath:options: method of the source object to create the connection between it and its target object. The screenshot shows dragging a view controller onto the canvas. As you add objects to Interface Builder, you resize them by their handles and reposition them by dragging.
As you move items, dashed blue lines help you align and position the item within the view. Above the library bar in the utilities area are the Interface Builder inspectors. In the screenshot below, the Attributes Inspector button is used to specify the button type Custom.
For more help with adding objects and other items, see Xcode Help. You can find and replace strings in storyboards and xib files using the built-in find commands. This includes finding symbols and strings in user interface elements. Project wide searches include xib and storyboard files.
Finding Editor Help. Designing with Storyboards. All rights reserved. I am trying to move from xcode 3. But when I build project, it gives error:. The document "filename. Navigate to your Classes directory. Do you see the filename. Then add it to your project. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Asked 10 years, 1 month ago. Active 10 years, 1 month ago.
Viewed times. But when I build project, it gives error: The document "filename. The file is not full screen View with status bar, it is freeform view. Thanks, Jignesh. Improve this question.
0コメント