I looked over the following threads:
1.What's the difference between outlet and referencing outlet in a simple sentence?
2.What is a referencing outlet?
But still have a big trouble understanding of why we need referencing outlet. Functionally, I mean. Could anyone give as detailed as possible example, explaining it to a beginner?
Right now I am going through Big Nerd Ranch textbook on iOS and they have in 10th chapter (about UINavigationController) a view that has three textfields. They make outlets in a controller and connect them to the textfields. But then happens what I can not get: they say to also connect these fields to the File Owner's delegate. Why do we need to do this?
At the end of Chapter 10, you'll encounter a code like this
item.itemName = self.nameField.text;
item.serialNumber = self.nameField.text;
item.valueInDollars = [self.valueField.text intValue];
To put it in simpler terms, we need to connect these textFields to make a reference to these outlets.(nameField, serialNumberField, valueField)
If we don't make a reference to these outlets, xCode would not be able to tell which text field the user is referring to when the user edits each text field.
As for why we connect text fields to the File Owner's delegate? We need to do this so that view controller can conform to a protocol and then later call [self.view endEditing:YES] which tells xCode when the user is done editing text fields.
Look at the end of Chapter 7 "Delegates" and "Protocols" for more information.
Related
I've recently started working with Xcode, having come from a C# background. I'm struggling to implement something for OSX that I'd find fairly trivial in C#.
Basically, I want to create a model that contains, say, two points. I then want to open a window which contains a Custom View that is linked to an object that is a subclass of NSView. I then want to draw a line between those two points using the dirtyRect function of my NSView based object.
I've followed examples for this & it works fine. However, I want to be able to open a number of windows, each of the same type of view so the data is displayed using the same technique, but having each one associated with a different model.
How can I let my NSView based object know what model data it should be drawing? I assume I'm missing something stupidly simple here...
Thanks,
Tom.
I’ve been reading through several books on Mac development, but cannot find the information I’m looking for.
The books all describe how to make floating windows or panes, but never mention how to make them all in one window. A simplified example of what I’m looking to create is shown below:
Basically, there will be three windows; A selector window with radio buttons to choose which NSDocument is currently being used, a window underneath that with buttons that show different windows to the right that allow viewing and manipulation of certain data.
For a example, each NSDocument may have a color value that can be set in the window shown by clicking view A, and some text strings that can be set in the window shown by clicking view B.
So the questions are:
Is it appropriate to use a single NSDocument sub-class for each Doc #1 and Doc #2?
Which classes should I use to set up the application as shown? NSWindowController? NSWindow? NSPanel?
I’m only looking for guidance on what to read up on, so any pointers are appreciated.
EDIT:
To clarify this further, I want to have a table view where the buttons are (View A & B), and by clicking them they will cause the other window/view to change it's contents.
It's like the split view in the iPad settings application, there is a table view on the left, and when it's pressed the right side changes.
The radio buttons are there only to illustrate that I want more than one Document. I'm guessing I need more than one to handle this? Or perhaps I should place them all in a single NSDocument? Somehow that doesn't seem right.
To achieve what you want you need one window (NSWindow), one window controller and various views each with their own view controller. There are several ways you could set this up, all depending on your requirements:
You'd have at least 3 views (instances of NSView): one for the selection of the document class, one for the view selection and one for the content. Each view is controlled by a view controller (instance of NSViewController). Additionally you can opt to wrap the views in split views (NSSplitView) so your user can resize the real estate available to each view.
You have one window with a window controller. If you choose a Document based app template in Xcode, Xcode will generate a subclass of NSDocument which you can use as your window controller (or choose to use Core Data and Xcode will generate a subclass of NSPersistentDocument with all bells and whistles you need to access Core Data for document persistency).
So to come back to your questions:
1: Yes, but depending on your requirements. If Doc #1 is a completely different thing than Doc #2 than you might need to re-evaluate. For example Doc #1 might have completely different persistent requirements than #2.
2: There's no single scenario here, but one that worked for me: Take the project template for a document based app (with or without Core Data). Use the generated subclass of NSDocument (or NSPersistentDocument) as your window controller. Use NSView to implement the views in your window where each view is managed by its own controller, which is an instance of NSViewController.
I know this is an old question, but a way to do it how you want would be to use: ContainerViews and set their embed segue to be the view controllers you want.
I still have a long way to go learning Cocoa. I'm trying to learn to code a Table view just like the finder where there is a small icon to the left of the file listing. #1 Its not clear to me if those are two columns in a row or if that type of operation is handled as 1 column.
If someone could point me to a good, easy to follow example, I would appreciate it. I was able to follow one example and I can drag and drop files onto the view but it only displays the [files lastPathComponent]. I wasn't sure how to add the icon.
You are going to have to subclass NSCell if you want this. Here is a good example:
NSCell Image and Text Sample
While yes you could do as sosborn suggests, however if you're already using OSX 10.7 Lion, you can now (and should!) use NSViews instead. And specifically you can subclass NSTableCellView.
Personally, I would watch the WWDC video titled "View Based NSTableView Basic to Advanced" available here: https://developer.apple.com/videos/wwdc/2011/
This also includes sample code that will get you going.
I have a question regarding the importance of choosing the correct starting and ending points of a control-drag operation while setting actions using Interface Builder (3.2.3). This issue came up while working through an example in an introductory text. In the example project there is a very simple graphical window with a three NSTextFields (i.e. First Name, Last Name, Email) and one NSTextView. The interface for the controller class is declared in the header file as:
#interface EmailController : NSObject {
IBOutlet NSTextField *emailField;
IBOutlet NSTextField *firstNameField;
IBOutlet NSTextField *lastNameField;
IBOutlet NSTextView *resultTextView;
}
- (IBAction)textFieldChanged:(id)sender;
#end
The text makes a point in stating that when setting an action you begin the control-drag at the control. Specifically, the example starts with a control-drag from the First Name editable NSTextField text field to the EmailController instance where a small black window appears and where the action textFieldChanged action can be selected.
After the First Name editable box is connected to the action the text directs the reader to also connect the Last Name and Email editable boxes to the same action. However in these cases the text directs the reader to start the control-drag operation from the small circle to the right side of the textFieldChanged action in the black window of the controller instance and to end at the Last Name and Email editable boxes. This seems opposite to how I understand the general rule of starting at the control while setting an action.
No matter which points I choose as my start and my end I seem to get the same result. The actions listed in the Connector Inspector for the various objects always seem indifferent to which point I choose as my start. I wouldn't even consider it an issue if it wasn't that it seemed contradictory to the explicitly stated general rule. I did notice a problem when I tried doing the same thing with outlets.
Does it matter which point you choose as the start when connecting a control to an action?
Thanks
Does it matter which point you choose as the start when connecting a control to an action?
No.
Big Nerd Ranch recommends always dragging from sender to receiver (outlet to object or control to target) to make clear which direction the message(s) will go in. It's equally valid to drag in the other direction, but does not reinforce the message direction to new Cocoa and Cocoa Touch programmers.
(To be clear, that blog is authored by a former BNR class attendee, not by BNR or anyone working for BNR.)
After the First Name editable box is connected to the action the text directs the reader to also connect the Last Name and Email editable boxes to the same action. However in these cases the text directs the reader to start the control-drag operation from the small circle to the right side of the textFieldChanged action in the black window of the controller instance and to end at the Last Name and Email editable boxes. This seems opposite to how I understand the general rule of starting at the control while setting an action.
One advantage of the right-click-on-action-receiver-and-drag-from-the-actions way is that it's easier to connect a bunch of actions at once. That sounds like the best reason for the tutorial making an exception there, aside from just being by a different author or authors (I'm guessing) with a different way of doing things.
I'm a total newbie to programming in cocoa for the mac so this question is probably easy. I have a window, and on that window I have a Label.
I want to be able to update this label from my program with the current status or what's going on (eg. reading in file, parsing, etc.). My problem is that I don't know how to access the label and change it's text property. I tried "MyWindowName." hoping I would be able to reference the label from the Window. I don't even know what the labels name is, or even if it has a name.
How do I reference this label in my program to change it?
You probably need to go here and walk through some tutorials: http://www.cocoadevcentral.com/
A quick summary is that unlike other technologies, you don't access the controls directly (or shouldn't access them). Instead, you create outlets in a controller, which you then graphically connect to the controls and they update automagically. These tutorials will show you the way.
A label is just an NSTextField with different settings about editing/fonts, etc. Just make an outlet in your controller that connects to the view in Interface Builder, and you can change it like you would any other NSTextField.