I have a toolbar, in which is placed a UIBarButtonItem. The selector is targeted at a custom view of mine; a method with this signature:
-(IBAction)pop{code}
However, clicking it does not cause any action to occur. The buttonitem doesn't appear to respond to the click either, it just stays gray.
Linking a UIButton's TouchUpInside event to the pop method is fine, it operates the method and displays the popover. But as soon as I connect the BarButtonItem's selector to it instead, it stops responding.
Make sure the selector has no colon after it - #selector(pop). If you use #selector(pop:) it expects a (void)pop:(id)sender { ... } function.
Related
In my interface file I said I conform to the UIAlertViewProtocol and I implemented the alertView:clickedButtonAtIndex: method in my implementation file, and normally whenever the alertview button is pressed (the button that makes the alert go away)that method gets called. Well, it gets called most of the time, but for one of my alert views it doesn't get called after I press the cancel button on it, what would be a reason for this?
Oh Its because in one of my alert views for the delegate parameter i passed in nil instead of self, thats embarassing.
So in some of the apple sample code I see things like this for application testing:
[viewController press:[calcView viewWithTag: 6]]; // 6
However when I try to do that with my own viewcontrollers/views all I am getting is "No visible interface declares press"... where is the documentation for application SenTesting on iOS, and in particular how do you go about doing UI testing (programmatically press a button, etc) within iOS?
Without seeing the sample code, I would guess that the view controller has a UIAction -press:. It should expect the nib to wire button presses to this action.
Instead of simulating the event, the test directly calls the action touch event would call.
After looking a bit, I think you may want how to programmatically fake a touch event to a UIButton?.
First you need to get a reference to the UIButton. If it's already set as an outlet in the view controller, you can use that. So, I'll assume your viewController has an IBOutlet for that UIButton named 'button'
[viewController.button sendActionsForControlEvents:UIControlEventTouchUpInside];
For the Swift 2.0 solution
viewController.button.sendActionsForControlEvents(.TouchUpInside)
I have a little problem with adding actions on UITabBarItems. I am not using a TabBarController, just the tabbar with items.
I have tried the following in viewDidLoad:
[_myTabItem performSelectorOnMainThread:#selector(myfunction:) withObject:nil waitUntilDone:NO];
This is causing a Unrecognized Selector sent to instance exception.
Have anyone dealt with similar problem?
[_myTabItem performSelectorOnMainThread:#selector(myfunction:) withObject:nil waitUntilDone:NO];
from the above line of code its is clear that myfunction having an argument , but you are not passing any argument ,you set withObject:nil
Either pass required parameter for myfunction ,or just use simple myfunction { }
I’m not sure what you’re trying to accomplish using the performSelectorOnMainThread call. That just sends the tab bar item the myfunction: message, and obviously the bar item does not respond to that.
I don’t think the tab bar items are supposed to trigger actions. They are just building blocks for the tab bar, which then sends you – the delegate – all events as described by the UITabBarDelegate protocol. The protocol includes a tabBar:didSelectItem: method, which is how you respond to a tab bar item being pressed. (But in general, don’t think about tab bar items being pressed, think about tabs being selected.)
I have a Button1 which has IBAction. Also I set target and action for my button
- (void)setTarget:(id)target action:(SEL)action {
[self.Button1 addTarget:target action:action
forControlEvents:UIControlEventTouchUpInside];
}
So when I pressed the button firstly IBAction did what he should, and than action that I set to button. Is that order always be like that ?
If you are loading you view or view controller from a nib file then yes the pattern will always be the IBAction even first followed by the target you have added to the button.
In effect adding an IBAction in Interface Builder is really just telling IB to call ["UIControl" addTarget:"id" forControlEvents:"UIControlEvent"], and you can add multiple targets to a UIButton.
In effect your code will load everything from the NIB file first (if you are using initWithNib:named:), so this will call the addTarget function on the button first with the action you have specified in Interface Builder, then at some later point the setTarget function you have above will get called, which will add another target action to the button. A UIControls targets are stored in an array which is accessed in order and will trigger if control events are met in the order they were created in.
If you look in the header file for UIControl (the super class for UIButton) you will see that NSMutableArray* _targetActions is an array. So the order is guaranteed to fire like this unless you reorder this array after it is created at some point.
The UIAlertViewDelegate protocol defines two methods, alertView:clickedButtonAtIndex: and alertView:didDismissWithButtonIndex:, which seem to me to be identical in usefulness.
Why is there a clickedButtonAtIndex and a didDismissButtonWithIndex when they both do the same thing? I realize there is also a willDismissButtonWithIndex that happens before the alert view is dismissed, but is there any reason to use clickedButtonAtIndex instead of didDismissButtonWithIndex?
I found a more useful difference between the two:
When showing a UIAlertView, and the device goes to sleep, alertView:didDismissWithButtonAtIndex: gets called, even though the alert view is not actually dismissed. It is shown again once the device wakes up. alertView:clickedButtonAtIndex: is only called when the user clicks one of the buttons.
The alertView:clickedButtonAtIndex: is called when the user clicks a button on an alert view whereas the alertView:didDismissWithButtonIndex: is called after an alert view is dismissed from the screen. (See the UIAlertViewDelegate Protocol Reference.)
The difference is minimal but it allows you to do something before or after animation.
If the alert view disappears for any reason (including being covered by another UIAlertView, going to sleep, etc.), didDismissWithButtonAtIndex: is called. This can mean that the method can be called even without the user clicking on anything. This can lead to unexpected behaviour if you depend on this delegate callback to be called in response to the user actually clicking on a button. In this case clickedButtonAtIndex: is more useful.
I couldn't reproduce Ed's behaviour by locking my device with the alert view present on iOS 7.
However, the most important difference between alertView:clickedButtonAtIndex:, alertView:didDismissWithButtonIndex: and alertView:willDismissWithButtonIndex: is that the first method (clickedButtonAtIndex:) is only called when the user explicitly taps on a button on your alert view (hence 'clicked').
Is it possible that an alert view is dismissed without clicking on a button? Yes, you could programmatically hide an alert view using the UIAlertView method dismissWithClickedButtonIndex:animated:.
So, if you need some behavior to be always triggered upon the dismissal of the alert view—whether it was triggered by the user tapping on a button or triggered programmatically—then using the didDismissWithButtonIndex: and willDismissWithButtonIndex: makes more sense.