I am used to programming for the iPhone. There, I would connect a button to an action, and then a method by creating the method like so: -(IBAction) DoStuff{…}. Then I would make an outlet for the button, and then the actual button in Interface Builder. I would then connect the button to the outlet, and then connect the button to the action by clicking on the circle next to Touch Up Inside and drag it over to File's Owner and select my action.
I am new to programming for the Mac, so I tried to drag from performClick to the file I wanted, but it wouldn't let me make the connection. Do I have to do this programmatically or what? How do I get this button to trigger an action in my code?
The fundamental difference is that iOS controls can have multiple actions for different events, but Mac OS X controls only have one primary action (in some cases, there are others that can be set up programatically).
When you right-click on a button in a Mac nib, performClick: is under Received Actions; it’s not an event. The only entry under Sent Actions is “selector”, which is the only thing you can connect to an action on another object.
Because there is only one “sent event”, you’ll normally just control-drag/right-drag from the control to the target and select the action rather than control-clicking, selecting the event and dragging from that.
It works much the same, but unlike UIKit there is only one signature for actions:
- (IBAction)actionName:(id)sender;
See Communicating with Objects and Target/Action in Interface Builder for more.
I like to Control-Click on the button and then drag to the object that I want to recieve the action. I then select the method of possible choices from the popup menu.
Related
Inside my .xib, I've placed an NSColorWell inside an NSView, and connected an IBAction in the controller to the NSColorWell's Sent Actions (via File's Owner). I figured I would respond to a click in my controller and send activate to bring up the NSColorPanel.
But unlike other my controls, I'm not getting the IBAction called. Clicking invokes a drag action on the color. I noticed this control doesn't derive from NSActionCell (like all my other controls). What's the proper control that is supposed to be used to both display a color and invoke the NSColorWell when clicked?
(note: this is Xcode/IB 3.2.x)
You listed both osx and ios in the tags, but I'm guessing this is an OS X problem.
There is a "Bordered" checkbox in IB's Attributes Inspector for NSColorWell. This toggles between a button-style color well, which is what you're asking for, and a color well which you can only drag a color swatch from. Make sure that's checked and you'll get the action like you're expecting.
Short answer is inside the title :)
Explaining: in my MainMenu.xib I have only the Main Menu of the application, that must be same for all NSWindows I open. There is one particular NSWindowController that has, let me say, all answers about when menu item must be enabled (via cases on selector in validateUserInterfaceItem) and what to do with all actions. When NSWindow associated with that NSWindowController is currently focused, there is no problem, but as I focus on another NSWindow all menus are grayed.
I have this flow now: MainMenu is created by reference to it as Main nib into info.plist, then AppDelegate do some init stuff and create MainWinController with MainWindow, at some point MainWinController creates 1+ DetailsWinController with DetailsWindow. AppDelegate manage my custom menu by calling each time functions from MainWinController.
So, how can I force the responder chain to query always that particular NSWindowController (MainWinController)?
You don't give many details to go on, and it isn't clear what you are trying to achieve.
My first reaction is that if you want share Menu items why are you creating multiple windows rather than Views within your MainWindow?
Assuming both your MainWindow and DetailsWindow implement the same selectors you could direct Menu Actions to the First Responder
To add the DetailsWinController in the InterfaceBuilder drag an NSObject from the Object Library, then in Identity Inspector change its class to your DetailsWinController class.
If your Main Menu has different items for the DetailsWindow just connect these to the actions in that instance.
NOTE if you so this you should NOT create the DetailsWinController in code.
If you really want to do this in code you will need to add actions and targets to your menu in code.
Sorry for the complicated title, but it's hard to explain.
This is the hierarchy I have:
Custom View
Custom View
Push Button
Box
WebView
WebView
The way my code works, is that the 'Box' has a 'setContentView' to one of the 2 WebViews shown above. So basically the Box can have a different WebView at any time.
I have the Push Button, which I want to assign to 'Go Back' on the WebView. But I need this button to 'Go Back' on the WebView which is within the Box.
So whenever the WebViews are switched around, the Push Button should link itself to whichever WebView is in the Box, and visaversa.
Is this even possible?
Thanks in advance everyone!
If you had an IBOutlet for your box (called theBox) defined in whichever custom view your button's action method is in, you can just use this in that action method:
[(WebView *)self.theBox.contentView goBack];
So whenever the WebViews are switched around, the Push Button should
link itself to whichever WebView is in the Box, and visa versa.
Why not use a more conventional arrangement? Make the view controller the button's target, and have the action in the view controller take whatever action is appropriate. In this case, that would be adding the appropriate web view to the box.
Views normally don't know anything about how the application works. They just do what the controller tells them to do.
I am writing a notification system just like growl. The notification is a window and it's level is set to NSModalPanelWindowLevel. The only problem is, I have a button in that window and when the user wants to click that button, he/she has to click it twice. But, for example, in growl, no matter what window you have opened, you just simply click the notification and it registers a click.
So is it a level problem? If so, what should I set it to? Thanks
In your custom controls that make up the view content of the window, you will likely want to override NSView's -acceptsFirstMouse: method to return YES:
Discussion
The receiver can either
return a value unconditionally or use
the location of theEvent to determine
whether or not it wants the event. The
default implementation ignores
theEvent and returns NO.
Override this method in a subclass to
allow instances to respond to
click-through. This allows the user to
click on a view in an inactive window,
activating the view with one click,
instead of clicking first to make the
window active and then clicking the
view. Most view objects refuse a
click-through attempt, so the event
simply activates the window. Many
control objects, however, such as
instances of NSButton and NSSlider, do
accept them, so the user can
immediately manipulate the control
without having to release the mouse
button.
Not sure if this is what Growl does, but you might be able to listen for mouse over events in the window and use them to activate/deactivate the window prior to the click. I suspect your issue is that the first click is being eaten by the activation of the window.
Just a guess on that though.
To learn how to handle mouse over events, check out this documentation:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html
Hi need a little help, i have a window which is set to always show in the top right corner but it is not set to always key. The window has a few buttons on it and when a button is clicked the window becomes key, but what i want it to do is when a button is clicked i want the window to remove itself from being key.
So ideally the window becomes key when a button is clicked and in the method which the button calls i want to write a statement which will then perform the action of the button and remove the window from key.
However the window is declared under the app delegate and the method linked to the button is declared in a separate header file.
Anyone have any ideas how i can do this, any help would be much appreciated.
Thanks in advance, Sami.
There are a few solutions depending on the architecture of your application.
Send [[NSApp mainWindow] makeKeyWindow], which will make the main window become key.
Your application delegate could have a reference to the main window. In the action method that handles the button click, you could ask the application delegate to make the main window become key. The application delegate would send [mainWindow makeKeyWindow].
Your application delegate could have a reference to the window controller that manages the main window. In the action method that handles the button click, you could ask the application delegate to make the main window become key. The application delegate would ask the main window controller to do that, and the main window controller would send [[self window] makeKeyWindow].
Your application delegate could listen to the NSWindowDidResignKeyNotification notification and keep a reference to the last window that resigned being key. In the action method that handles the button click, you could ask the application delegate to return key status to that previous window. The application delegate would need to ignore NSWindowDidResignKeyNotification notifications when the window is your auxiliary window. This solution is better when there’s no single main window.
If the first solution is not applicable, a) your application delegate could conform to a protocol that declares a method responsible for restoring key status to the proper window, or b) your action method could post a notification informing the application that your action method has completed, and have the application delegate listen to that notification and restore key status to the proper window.
Note that even though I’ve suggested that the application delegate would implement the behaviour of restoring key status, other objects could be responsible for that. This is particularly easier when notifications are used since there’s no need to grab a reference to the object that will restore key status due to the inherent loose coupling provided by notifications.