Must a button control be added as a property in the Interface? - objective-c

I'm new to Objective C and there are a few basic things that I do not yet understand from the tutorials and books I've looked at. For this question I am confused about whether a button needs to be connected to a property in the Interface as well as being connected to the IBAction method.
Seems like a simple question that might help others. Thank you.

You should hook up items in interface builder to IBOutlets only if you need to operate on them in the view controller. For instance, if you wanted to change the button's title text to be localized on load, then you would hook it up. If all you want to do is respond to a specific action on the button (touch up inside for instance), then you only need to hook up the IBAction portion. The short answer is that you are not required to hook up the IBOutlet.

Related

NSTextfield renaming implementation on custom button in NSTableView

I have NSTableView and a button in NSTableViewCell. I want to implement the functionality when the user clicks on my NSButton and cell goes to the renaming mode of its NSTextField.
I already set up action outlet for button and know when it's clicked but can't really find any info on how to trigger renaming. The answer might be pretty easy but I can't get to it. Thank you in advance!
P.S. I use Swift but any help would be great
Well, the answer is actually very easy, it's the lack of related information that makes it kinda hard.
So, in case anybody's looking for the same thing, that's how I implemented this feature(it's actually one-liner):
in your action outlet just call
cell.textField?.selectText(self)
and the text's gonna get selected. After that just keep implementing it as usual.

The UIButtonBarItems and UIPopovercontroller references in UISplitViewController delegate methods

I could use some clarification regarding where these references come from. As an experiment, I set up a split view controller in my application. When the delegate methods are called, they reference what appears to be a valid UIButtonBarItem and a valid UIPopoverController. I say "apparently" because both of these have non-nil values and resolve to the appropriate class (UIButtonBarItem and UIPopoverController). I did not allocate or initialize either one. Am I supposed to?
I don't see anything in the reference documentation that requires that I initialize these programmatically or says how it should be done. I also don't see where the toolbar that contains the UIButtonBarItem is referred to. I haven't found any examples of tutorials that address this detail more than superficially. If someone can explain or provide a reference to an explanation, that would be helpful.
I am working out how to switch from split view to popover view when going into the portrait orientation. I want simply link an existing button to code that does what the UIButtonBarItem would do. I have a small banner view of my own that serves as a toolbar, and I would rather adapt the button in that to work with the split view controller, if I can.
The UISplitViewController creates both of these for you and you can do with them what you want. Just add the button that it provides you to your toolbar and store a reference to the popover (so that you can dismiss it, etc.).
Note that when you go back into landscape mode you need to set your popover variable to nil and remove your button since they are no longer valid.

Handling mouse events on NSButton created in Interface Builder

I had a class project consisting in programming a swype-like. I had to do it in java, and you can have a look at it (with the code) here. For this summer, I'd like to port it in ObjC/Cocoa, and then improve it. I intend to use NSButtons for the keyboard keys, like the "Gradient Button" proposed by Interface Builder.
So, I looked about how to handle mouse events (I need mouse pressed, entered, exited, and released). For some objects, it looks like you have to use a delegate, but for NSButton, looks like the methods like -mouseDown and related are in the object itself.
My question is, how do I override the methods in interface builder objects ? I tried creating a subclass of NSButton, and setting my button's class to this subclass, but without results. Maybe trying to override the methods is not the right way to do it at all, I'm open to every suggestion, even if it is not event-handling related. And if it is relevant, I'm running OS X 10.6, with XCode 4.
Thanks for your time !
A lot will depend on why you need all of the various events. NSButton is a control, and as such works differently than a standard NSView.
If you mostly need to figure out when the button is pressed, you can do this by assigning an action in IB. This is done by creating a void method in your controller class of the form:
- (IBAction) myMouseAction:(id)sender
and then having it do what you need based on receiving the click. Then in IB, you can hook up this action to the button by control-clicking on the button and dragging to your controller class (likely the owner) and selecting your new method when prompted.
If you need fine-grained control, you should consider creating your own NSView subclass and handling the mouse actions yourself, as trying to override controls is a pretty complicated matter. OS X controls were architected for extreme performance, but they're a bit anachronistic now and generally not worth the work to create your own.
One other thing is that the mouseEntered:, mouseMoved: and mouseExited: events are for handling mouse movement with the mouse button up.
You are going to want to pay attention to: mouseDown:, mouseUp: and mouseDragged: in order to handle events while the mouse button is being held down.

Is assigning the same Action-method to multiple Cocoa UI objects e.g. NSButton possible?

I'm currently learning ObjC and Cocoa programming, coming from the Java world.
To test my current skills and learning progress I'm creating a small calculator app from scratch (OSX not iOS).
My UI has 10 digit buttons 0-9 among others.
My first thought was, since the action receives the senders reference, to make one action
like -(IBAction)captureDigit:(id)sender and then just grab the digit from the button title.
But the interface builder only allows an action to be connected with one sender it seems.
So I ended up creating 10 captureDigit actions in my controller.
My Question:
is the first option possible somehow? I thought of adding the actions programmatically (is this possible?) to the buttons, but then I would have to add all digit buttons as outlets to my controller.
Bonus Question:
can a NSButton hold some kind of non visible value? Could not find this in the documentation.
Maybe this would violate the MVC pattern as the UI would then know of application specific data?
Thanks for any useful and kind answer in advance, I'm still learning
You can connect many senders to one target/action if you Control-drag from senders to the target, so that's not a problem.
WRT your bonus question, any NSView has an integer tag which you can set in Interface Builder. That's a convenient way to differentiate multiple similar views.
You can definitely connect more than more button to a single action. Also, you can use the tag field of any object to give it a "behind the scenes" value.
It's perfectly possible to add as many actions to a single controller. How is Interface Builder preventing you from doing this?
You could have a NSDictionary instance in your controller, in which you could match NSButtons to whatever data you want.
To make it easy, in IB create one button and drag from NSButton to File's owner it then shows all of the methods that we can send to NSButton, then select captureDigit:. Now copy and paste the button change the title, copy and paste in IB keeps the connection and use tag field as costique, nitrex have already said.

Class Design for delegate, outlets, and mouse events

Here's a simplification:
I have an application with several buttons. If it is the first time the application is launching, I want to do some special things. In my AppController class, which is a delegate of NSApp, I use the delegate method -applicationDidFinishLaunching: to perform the test. After I've detected that it is the first time, I first want to access some IBOutlets. Then, I'd like to be able to get mouse events for each button, so that I can do other things.
I can't figure out want to do with the classes. I'd like to make a new class (FirstLaunch) for the first launch, but I'm not sure what to call from AppDelegate. Also, to get mouse events, shouldn't I be a sublass of the buttons, and considering that I have multiple buttons, I'm confused. I could probably tackle these issues one-by-one, but taken all together, they're confusing me.
Broken down, I need to access & manipulate IBOutlets I have set in IB, determine when buttons are clicked (and which button was clicked). I'd like to be able to do this from another class so as to not clutter up the AppDelegate.
Thanks for the help!
To be more clear, what I'm actually trying to do is to use Matt Gemmel's MAAttachedWindow to put up a help bubble by a button. When the button is clicked clicked, the bubble disappears and another one is put somewhere else. The bubbles will be attached to controls in the main window.
I'm guessing you want to show some additional user interface on the first launch? If it's a separate window, I'd advise creating a subclass of NSWindowController. Add a new NIB file for the first-run user interface to your project and change the class of the File's Owner object to FirstLaunch. Control-drag a wire from the File's Owner delegate onto the window to connect it with the window outlet.
You create IBOutlets by adding an instance variable to the class. If your app will only run on Leopard or higher, it's better to declare your outlets like this:
#interface FirstLaunch : NSWindowController {
NSTextField *myTextField;
}
#property (nonatomic, retain) IBOutlet NSTextField *myTextField;
#end
In Interface Builder, you'll control-drag a wire from the File's Owner onto the control to associate it with that outlet. Make sure that you release your reference to each IBOutlet in your class's dealloc method (if you're not using garbage collection) or else your app will leak memory.
Buttons send action messages when they're clicked, so you'll need to provide an action method for the button to call. You do that by declaring a method with a signature like this:
- (IBAction)myButtonClicked:(id)sender;
In Interface Builder, you'll control-drag a wire from the button onto your window controller and choose the myButtonClicked: method.
To make all this work, you'll need to create an instance of the window controller and tell it to load the NIB file at runtime. So, in your AppDelegate class, when you've determined that this is the first launch, you'll do this:
FirstLaunch *firstLaunchController = [[FirstLaunch alloc] initWithWindowNibName:#"nameOfNibFile"];
[firstLaunchController show:self];
You'll probably want to keep the reference to the window controller in an instance variable instead of a local variable like I've done here. And, depending on your application, it may make more sense to show this as a sheet. But once you've made it this far, you'll be able to figure out how to do that on your own.
Then, I'd like to be able to get mouse events for each button, so that I can do other things.
Don't worry about the mouse. There may not even be a mouse (think of the ever-popular tablet-Mac rumor).
I'd like to make a new class (FirstLaunch) for the first launch, but I'm not sure what to call from AppDelegate.
You make your own methods here. You'll probably make it a singleton*; then, you'll implement a method named something like runFirstLaunchPanel:, which will be an action method (more on those in a moment):
- (IBAction) runFirstLaunchPanel:(id)sender;
Instantiate the object in the nib, then, from your app delegate, call the action method with nil as the sender.
The reason to put the object in your nib and make the method an action method is that this makes it easy to hook up a menu item to it, so that the user can re-run the first-launch panel at a later time. (For example, if it's a Starting Points window, you might connect the New menu item to this action instead of the default one.)
*Yes, I've seen the articles about singletons, and I agree with them. In a case like this, it's OK.
Also, to get mouse events,
This is the wrong way of thinking about it. What you need to do is set your button up to send a message to your controller to make the controller (probably AppDelegate) do something. The message you want the button to send is an action message.
Implement an action method in the object that owns the nib containing the window with the buttons. Declare this method in the class's header, then connect the button to it in IB by right-clicking on your controller and dragging from the correct action method's circle to the button.
This is called the target-action paradigm, and it insulates controller responsibilities (doing things) from the views that ordered them. Because each action method does only one thing, you can have a button, a menu item, and even another controller (your app delegate, above) send the same action message, and the receiving controller won't have to care which control is sending the action, because it already knows what it has to do.
shouldn't I be a sublass of the buttons,
No. You very rarely create subclasses of anything other than NSObject (or, for model objects in Core Data, NSManagedObject) in Cocoa.
Note that I said “rarely”, not “never”. You will have to make the occasional subclass, especially if you want to create custom or customized views and cells (and, maybe, customized windows). However, subclassing is not necessary in Cocoa to the degree that (I hear) it is in some other frameworks on other platforms.
and considering that I have multiple buttons, I'm confused.
The target-action paradigm means you don't have to create one button subclass per button. One controller class implements all the actions, and the stock buttons, because you've hooked them up in IB, simply tell the controller “do this”.
Broken down, I need to access & manipulate IBOutlets I have set in IB,
Probably not. At least, not as much as you think you do.
determine when buttons are clicked (and which button was clicked).
Nope. The buttons will worry about being clicked; you just worry about setting them up to send, and then responding to, their action messages.