When connecting a button in Xcode as #IBAction func, we can choose between Arguments: Sender or None.
When do we choose Sender and when None?
Well, if the action method needs to know which button triggered it, or can make use of any of the button's properties, then you would need to pass the sender (the button) to the method.
A contrived example for this would be if you have a calculator, which has a '+' and a '-' button. They both could share the action method performCalculation(sender: NSButton) and the method could use the sender's symbol (this would be the button's title) to perform the correct calculation.
On the other hand, if you have a button, that will for example clear all input on a textfield, then you would wire this button up to a method clearInput() which would not need to have any information about the button that triggered it (in fact, having no argument here would make it easier to reuse this method elsewhere in your code and trigger clearing the textfield programmatically).
I hope this makes sense to you. There are no clear rules afaik. It's mostly a matter of taste I guess.
Related
I have over 30 buttons and 30 images inside of a switch statement, 4 buttons showing at the same time. I want to perform an IBAction depending on which button is pressed. It's not allowing me to drag & drop it into the case inside my switch statement. The buttons change depending on what image is showing. For every image, there are 3 wrong buttons, and 1 correct button. How can I check for which button is pressed, and add a resulting action?
You are getting it totally wrong. You should use switch statement to control look and feel of UI. Like controlling the 4 buttons to be shown by simply using hide property.
Each button should have an IBAction defined at class level. So, drag and drop connection from XIB/Storyboard to class and not inside switch statement. Depending on which button is currently shown, it action would be triggered.
EDIT: Post OP clarification:
Since you are trying to set different image on same button based on some condition and want to handle the IBAction based on the kind of image you set on it, you would need to set the tag on the button in your switch statement where you are setting images. tag takes an integer value so you can create enum for readability. Then when button is tapped and your IBAction is triggered, put another switch statement to check the value of tag and then take action accordingly.
I'm a bit of a newbie so I apologize if this is an easy question.
I'm following this tutorial: http://www.truiton.com/2015/03/android-cardview-example/#comment-7174
It shows how to make a few CardViews in a layout with 2 TextViews in each - all programmatically.
I would like to modify it to have a Button instead of the TextViews and to have each Button make a Toast notification upon press. I am currently stuck because I have no context to make the Toast with (because I can only access the buttons in the MyRecyclerViewAdapter class). How may I solve this?
Well the fact that you have access to a button, means you have acces to a context. and to my knowledge, a onclick event on a button means that the button is still alive, and then you could assume that the context for the button is still active. The way to get the context from a view is very simple:
view.getContext();
The reason i mention the assumtion is that, relying on a view's context, could be a bad idea (for example after calling a webservice or something else, where a view could have been destroyed).
In a UIView I have a nav button with an IBAction & method in the top-level view controller.
In the IBAction code, I flip a boolean so that when execution returns to the UIView, there's some new setup prior to drawRect: repainting the view.
If all this were in the ViewController, I could put the new setup code in something like ViewDidAppear so it executes each time the button is pressed. However, there's no such method at the UIView level. There is initWithCoder, but this only seems to be executed once (when the storyboard/nib loads).
So my question is - either, is there a way to call the initiWithCoder method explicitly from my IBAction at the VC level (I've tried [self initWithCoder:nil] but the breakpoint at the UIView level doesn't trigger) or is there a method that runs when execution returns to the UIView level, a la ViewDidAppear?
Thanks
Image of goal:
Unless you really know what you're doing (I mean really know), don't call -initWithCoder: yourself. You're meant to implement it just as you implement -drawRect: and let the system call it. If you ever find yourself calling something like this directly and you can't explain the deep technical reasons why there's no other way, then it's the wrong approach. Read and follow the documentation (not just the method's doc) to make sure you understand whatever method you're using. It'll tell you.
That said, what you're wondering is if there's a point in a view's lifecycle where you can "do something" (check a BOOL and perform some work if YES/NO) any time the view "appears". The answer is yes, and -willMoveToSuperview "can" work.
BUT
That's the "wrong" approach, IMO. The BOOL property ('draw a twiddle next time I'm asked to draw) can and probably should live in the UIView, but its state should be set in its controller since this is specific to your app. Views are supposed to be (highly) reusable; controllers are supposed to implement your app's specific logic and drive the views according to the model state and user (or system) actions.
So: when you want to enable the "draw a twiddle" operation, your view controller should set the view instance's drawTwiddle flag then probably flag the view for drawing. Your view will then have -drawRect: called at some point you shouldn't try to control and, when it does, it sees that self.drawTwiddle == YES and draws the twiddle along with whatever other drawing it does.
At that point, you might be tempted to have the view set its own drawTwiddle flag to NO since the behavior is intended to fire once. Don't do this. BEWARE: Other user actions or system events may call -drawRect: at any time so the twiddle may not actually be seen by the user (it may appear and disappear faster than is visible). 'So', the right thing to do is to make the controller (via some direct action, system event, or timer) responsible for setting and unsetting the drawTwiddle flag, then flagging the view for redisplay.
Adding
It's also unusual to put an IBOutlet or an IBAction in a UIView. Most of the time, unless you're creating some compound control whose parts aren't intended to be accessed and managed individually, your architecture is clearer (and more closely follows the spirit of the MVC design pattern) by letting the controller manage/own the outlets and actions.
Is there a way to hide the pop-up button of an NSComboBox? I can't find anything in the documentation for NSComboBox or NSComboBoxCell. There is a setButtonBordered: method on NSComboBox, but this just changes to an alterate button style.
If I can't hide it, can I at least disable it?
If the combo box has no items, clicking the pop-up button doesn't do anything.
Maybe you can work around the limitation by emptying the list when you want to disable the button.
It makes clicking have no effect, but it doesn't hide the button or draw it as disabled.
I don't think this is possible. An NSComboBox without the button is effectively an NSTextField, so I guess it was deemed unnecessary. You could probably do this by subclassing NSComboBoxCell and override -drawWithFrame:inView: or -drawInteriorWithFrame:inView:.
Safest way would probably be to add your own buttonHidden property and use the ObjC runtime method class_getMethodImplementation to look up the IMP for the same method in NSTextField and just call that when the button is hidden. You'd effectively be calling super's super, so you'd get a regular text field look.
you can disable it by doing:
myComboBox.Enabled = false;
In Cocoa, how do you define a class that sends an action? I want to be able to connect the action to the selector of another object in IB in the style of NSButton. I would prefer not to subclass NSControl if possible.
Give it a property (informal is fine) holding an id, for the target. I'm not sure whether this should retain or not; I'd say no, since the target will normally be the controller that owns the window that (indirectly) owns the view.
Give it a property (informal in fine) holding a SEL, for the action.
Respond to mouseUp: and keyDown: (checking that the key in question is the space bar or return or enter) by sending yourself an accessibilityPerformAction: message, passing NSAccessibilityPressAction.
Respond to the accessibilityPerformAction: message by either sending your action message to your target (NSAccessibilityPressAction) or calling up to super (other), as described in the documentation for that method.
You should also implement the rest of the NSAccessibility protocol while you're at it. Test that work with a mix of the Accessibility Inspector and VoiceOver.