I have a view with several buttons that all have the same target and action.
At the moment the action is #selector(doSomething).
I need to be able to determine which button is pressed but I'm not sure of the best way to do this.
The method doSomething is declared as...
-(void)doSomething;
Is there a better way to declare this so I can get more info out?
Thanks for any help!
Oliver
If you declare the method as
- (void)doSomething:(UIButton *)sender
with the corresponding selector #selector(doSomething:), then you can check the identity of the sender using either of the methods Joshua suggested.
Target/action messages provide the sender as the argument. In your case, the button that called the message is the sender. You could ask it for its -tag (which you can set in IB) or you could name it as an outlet and test for equality: if (sender == myButtonOne) ...
Related
I got only so far to be able to switch a view by pressing a button or with a timer. But I don't get it to switch a view by events like didReceiveLocalNotification. Is it impossible to do this?
Yes, that's possible , Because usually we specify the method with notification in which we wish to receive it.
Put the same code from your UIButton action: to notification method.
Yes, all you have to do is doing the switch inside the method didReceiveLocalNotification.
You will need to send a message to the view controller you want to perform the switch.
It seems that UISegmentedControl objects only send out "UIControlEventValueChanged" events. Is it possible to make them emit "UIControlEventTouchDown" events also ?
Have tried to right click the control in IB and then connect the "UIControlEventTouchDown" event option to an IBAction method, but no event is sent out. Have also tried to do it in code using an "action : #selector" statement but also no event.
In both cases, when I change the event to "UIControlEventValueChanged", the event is sent out as expected.
Hope that somebody who is knowledgeable on this can help ...
You could use the addGestureRecognizer: method inherited from UIView
What does it actually mean to set the delegate of a textfield?
For example: txtField.delegate = self
"In short, that you are receiving calls from the txtField. You are setting the object 'self' as the delegate for txtField."
"That means that your 'txtField' will receive events from itself
These two answers essentially mean the same thing. But seemingly contradictory. But the first makes more sense to me. I can see why a beginner gets confused, I've been there!
Basically one is the caller one is the receiver Think of it as a chef in a kitchen call his assistant to cut up some onions. In this particular case, txtField is the chef, "self" is the assistant. txtField orders self "Do this, this and this!" Like it or not the assistant has to oblige cuz he has wife and kids to feed. :)
It means that self will be the recipient of certain method calls that are made in response to actions on the text field.
In short, that you are receiving calls from the txtField. You are setting the object 'self' as the delegate for txtField.
Delegating is a programming pattern that is widely used in Objective-C.
The basic idea is let an object delegate some tasks to another object. For example, your UITextField object delegate some tasks to your view controller. In this case, your UITextField object becomes a delegating object, and the view controller the delegate of the UITextField object. The delegating object sends certain messages to its delegate in order to get necessary information, or to notify certain events, etc.
That means that your 'txtField' will receive events from itself (kind of a weird example, maybe a larger source code section could be provided?)
For some of its methods, the textfield (any object in a class using the delegation pattern) is going to try to call some other object to so that that object can customize some of the textfield's behaviors. The object that the textfield will try call is called it's delegate. The delegate is initially set to nil, so, by default, no customization happens.
If a class has a line of code like: textfield.delegate = self; then it says that this object in this class wants to get called to handle the textfield's customization for certain of the textfield's defined delegate methods.
It means the actual class where 'txtField.delegate =self' is called will receive callsbacks from events. This is often a convenient way to do things.
Are there any issues when using IBAction when it is not actually called from a user's action?
If you have an action like
-(IBAction)sayHello:(id)sender;
You can call it from within your class like:
[self sayHello:#"x"]
The #"x" doesn't do anything, it just fills in for the sender.
You can actually create an IBAction method without (id)sender
-(IBAction)sayHello;
and call it from both user's actions and from within the code, but then you won't get any useful sender info from the interface. What's the 'correct' way of filling in for the sender, when calling from the code? And can you create sender info to send when it's called from within the code?
Just trying to figure it out.
I think a good practice for OOP is to refractor the method
-(IBAction)sayHello:(id)sender;
to another method called: -(void)sayHello;
and inside the method
-(IBAction)sayHello:(id)sender {
[self sayHello];
}
If other methods want to call the sayHello:(id)sender action to do some job, it can call the sayHello. The method name should make sense for the client to call it without a problem or work around. It will help you when you have to test or debug
The sender should be a UI component. So if in your class you have, say, a UIButton...
UIButton *button;
Then you can just send it as parameter to the action:
[self sayHello:button];
Insider the method, no matter if it is called from the UI or in some simulated way, you can have some logic to detect who the sender is, and behave differently based on that. This way, multiple buttons or other components can reuse the same action method.
Unless you're actually making use of the sender parameter (see Jaanus's answer for more on that), you're fine with passing nil for it when calling the method from code.
I have a UIControl subclass for a custom slider type control (one that behaves differently from UISlider). At the moment I use my own target and action variables to send a message to the target whenever the slider value changes. But this doesn't play nice with Apple's UIControlEvent constants. I wasn't sure if I should use these, and if so, where can I put my custom "value changed" detection?
I overrode beginTrackingWithTouch: and continueTrackingWithTouch: to return YES but the action is never dispatched.
Every time the value changes you call [self sendActionsForControlEvents:UIControlEventValueChanged] and the control will handle the rest.
Make sure that you are passing touchesBegan and other inherited methods to super class.