anyone knows why UIViewController wouldn't become first responder when I run this code:
[self becomeFirstResponder];
NSLog(#"is first resp: %i",[self isFirstResponder]);
In the console, I always see the line: "is first resp: 0"
I HAVE canBecomeFirstResponder method:
- (BOOL)canBecomeFirstResponder {
return YES;
}
I don't even know where to look next....
Make sure you set your UIViewController to be first responder after you have assigned some view to your window instance.
Update
As I suspected, I assumed wrong about UIViewController/firstResponder usage. This thread in the apple dev forums talks specifically about getting shaking to work.
Original Answer
Call becomeFirstResponder on the UI element that you want to respond. The events will automatically get forwarded to the UIViewController as long as no other objects in the chain implement the touches methods (or at least keep forwarding them up the chain).
Side note: To build on the comments of others, it really doesn't make sense for a UIViewController to be the "first" responder. The first responder should be an object with an on screen representation (a UIView or one of its subclasses).
Although this may be a completely incorrect statement, there may be undocumented behavior in UIViewController that prevents it from becoming the firstResponder because of these issues (Someone smarter than me may be able to verify the validity of this).
Do you have a UIScrollView in that UIViewController?
Related
For the past few extremely frustrating days of my life, I've been trying to figure out what's wrong with me code. In a certain page, if I put UITextViews or UITextFields or a MFMailComposer or a MessageComposer or anything with fields that require editing, the fields just wouldn't respond to touches. I couldn't edit anything when I ran the app. I couldn't edit text views or email fields or anything. I tried everything, but nothing worked. It turns out that on the main page (MainVC) that leads to the page where fields don't respond (GiftVC), in the viewDidAppear method (in the MainVC), I say: [self becomeFirstResponder];.
Now I'm not really sure why I put that there, but it turns out that commenting that line out fixes everything and makes all the fields and textviews and email composers and everything work just fine again.
I also have this in the MainVC page:
-(BOOL)canBecomeFirstResponder {
return YES;
}
and commenting that out fixes the problem as well.
The weird part is that even with the [self becomeFirstResponder] line, everything worked just fine in the new iOS 5 (simulator and device), but in iOS 4 (simulator and device), it wouldn't work at all with that line. Now that I've removed it, it works fine in both cases.
If you have the following in your UIViewController subclass
- (BOOL)canBecomeFirstResponder
{
return YES;
}
- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
if (self.view.window) {
[self becomeFirstResponder];
}
}
then you probably intended to allow that subclass to handle motion events (shaking) or something similar. So that's probably why it's there.
If you weren't able to edit UITextFields then this subclass was probably becoming the first responder and not forwarding the event to the actual UITextField. When a UIViewController subclass calls overrides canBecomeFirstResponder to return YES and makes them self the first responder (ie [self becomeFirstResponder], if you want don't want that custom class to handle the touch events for the UITextField, then you should override the nextResponder method.
An example from my own product -- Essentially I have a UIViewController subclass that does two things: 1) it handles shake events and 2) it displays another view modally when some button is tapped. On the modal view there are some UITextFields. To allow my UIViewController subclass to forward the touch events to my modal view, I added the following:
- (UIResponder *)nextResponder
{
if (!self.view.window) {
// If the modal view is being displayed, forward events to it.
return self.modalViewController;
} else {
// Allow the superclass to handle event.
return [super nextResponder];
}
}
This will work on iOS 4 and 5, with either sdk.
Now, in your case you obviously didn't remember adding the code to become first responder in the first place, so you don't need the above hooks. However, it's good to know for the future.
Back to your actual question -- once you updated your SDK to 5, why wouldn't things work on iOS 4, but they would work on iOS 5? iOS 5 is doing some of the event forwarding for you which is why it works there. It should have never worked on iOS 4 in the beginning. Apple fixed some bugs that allowed it to work on 4, which is why it no longer works on 4.
I know the question had already accepted an accepted answer; I just wanted to clear up any confusion out there.
Check if MainVC has a method called canResignFirstResponder that returns NO (at least sometimes). If so, then once it becomes first responder, it won't let anything else become first responder, until it returns YES from that method. (All the UITextViews, etc. have to become first responder to be edited.)
Actually just look everywhere in all your code for canResignFirstResponder, in case it's in a superclass or something.
Otherwise the only thing that would stop the text fields and views from being editable would probably be if they got set userInteractionEnabled = NO, but since it hinges on the becomeFirstResponder statement, it is more likely to do with canResignFirstResponder.
In iOS 4, a subclass must override canBecomeFirstResponder in order to be able to become first responder. Maybe this is different for iOS 5 or it's a bug.
Try this,
Make sure you have added the uiTextViewDelegate and
- (BOOL)textViewShouldBeginEditing:(UITextView *)textView{
NSLog(#"textViewShouldBeginEditing:");
return YES;
}
For some reason, interaction with my UIButton only works once. I've tried both via IBAction, and by IBOutlet with "addTarget". I have no idea why.
Context:
BaseViewController
- (IBAction) button_touched:(id)sender; //<-- Declared here, but not implemented
- (void)userInputReceived:(BOOL)bSuccess; //<-- Declared here, but not implemented
ViewController1 : BaseViewController
- (IBAction) button_touched:(id)sender; //<-- Implemented here
- (void)userInputReceived:(BOOL)bSuccess; //<-- Implemented here
Also, this is where I try "addTarget" but that doesn't work either (first touch works, but not the second)
In the "button_touched" method of ViewController1 (vc1), I make a call to another class like this:
[someOtherClassObject doSomethingWithMyView:self];
That class simply pops up a message box, gets user input, then calls back on the viewcontroller:
(Inside SomeOtherClass):
-(void)doSomethingWithMyView:(BaseViewController*)vc
{
// Do Something
[vc userInputReceived:TRUE];
}
Once this workflow has executed once, the button touch never calls the "button_touch" method again. No matter what I do, I can't get this to be called again.
In a thread on one of the popular BBS forums, someone mentioned that a problem like this could be caused by not having the object (vc1) you think you do, but rather, another instance of it. So, I logged the instance like NSLog( "instance: %p", self) in numerous places, and it's always the same.
Any ideas are greatly appreciated. This is very frustrating.
shot in the dark maybe, but its possible that your view controller's view has lost first responder status due to the displaying of the message inside the other object (what type of object is this and how is the message displayed?).
Try after your statement:
[vc userInputReceived:TRUE];
adding the line
[[UIApplication sharedApplication].keyWindow makeFirstResponder:vc.view];
I've got a UITextField on UITableViewCell, and a button on another cell.
I click on UITextField (keyboard appears).
UITextField has the following method called:
- (BOOL)textFieldShouldBeginEditing:(UITextField *)textField {
NSLog(#"yes, it's being called");
owner.activeTextField = textField;
return YES;
};
Where owner.activeTextField is a (retain, nonatomic) property.
The problem
When the keyboard is visible I scroll the cell out of the view.
I then click a button that is on a different cell. The button calls:
[owner.activeTextField resignFirstResponder]
And that causes EXC_BAD_ACCESS.
Any idea? The cell is most definitely in the memory. My guess is that once it disappears it is removed from the view and one of it's properties (parent view?) becomes nil and that causes the said error..
Am I right?
TL;DR; How can I remove the keyboard (resign first responder) when UITextField is removed from the view?
Sometimes the problem can be another level deep... Check and make sure that the next object in the responder chain (the one that's subsequently receiving the becomeFirstResponder message) isn't garbage. Just a thought.
Have you checked owner.activeTextField to see if it has been deallocated / set to nil? Not sure if that would call a EXC_BAD_ACCESS but worth a try.
Also do you have any calls to NSNotificationCenter? I was struggling with something similar today which was causing an EXC_BAD_ACCESS on becomeFirstResponder, which was due to me calling [[NSNotificationCenter defaultCenter] removeObserver:keyboardObserver]; on the incorrect delegate.
A bit old, but since I just had the same problem with a legacy manual reference counting app, I'll give it a try. Note: this problem shouldn't happen with ARC anymore (and if it does, my solution most definitely doesn't fit there...).
What seems to happen is that:
the textfield is saved into the cell and is (possibly over)retained
when you scroll the cell with the textfield, the cell get's recycled (which is good), but the textfield is not (which is why the textfield is still in memory when the bug happens)
at that point, dismissing the keyboard correctly resign the first responder for the textfield, but as the call travels down the view hierarchy, it hits the cell, which is not in memory anymore.
a simple (and imo elegant) solution for the problem would be to
fix the over retention of uitextfield if any
subclass UITextField to resign first responder status before being deallocated
a single method,like this:
- (void) dealloc {
[self resignFirstResponder];
[super dealloc];
}
would be required, which will have the side-effect benefit of removing the keyboard as soon as the cell gets out of view.
Another solution (which is the one I chose, for various reasons) would be to manually retain and recycle the cell with the textfield until the table is deallocated.
i'm sure you already solved your problem, but I hope this will help someone else...
I am having quite a issue trying to change the cut/copy/paste behavior of the UITextView.
What I want to achieve is: detect when the user has pasted some text into the UITextView. When I detect this I will then check the data and do my thing.
According to the documents, I found out about UIResponder.
So I created an simple class that inherits UITextView.
in the .m file I create 1 function called.
-(void) paste:(id)sender{
NSLog(#"paste button was pressed do something");
}
But for some reason it never seems to fire. I could get the select statement working and tracing data.
-(void) select:(id)sender
1. Is this the correct way to detect Paste in a UITextView?
2. Right now I am tracking buy how many Characters UITextView changes and if its greater than one char then I suspect that it could be a paste operation. But since the iPhone can autocomplete words eg Wedn (goes to Wednesday) its possibly not a paste operation.
In Interface Builder, I selected my textView in my NIB file, and selected its "Class Identity" to my nearly created class before and I know that this file was working as a subclass but it just would not respond to the Paste event.
thanks.
UITextView has a view that handles the cut, copy, paste. It's UIWebDocumentView. So if UITextView is the first responder, UIWebDocumentView will get it first instead of your implementation. I would like to overwrite these functions so this is very frustrating.
Same thing happens to me too. Select (and copy sometimes) gets called but paste never.
I have simulated the behavior using textViewDidChange where I always verify the difference between the current text and the previous one. If there are more letters different and the text.length is bigger than it must have been pasted.
Hope Apple will fix this.
In case somebody still needs short and easy solution I'll share mine. I use wonderfull NSObject+REResponder category from REKit project. The solution is as easy as this:
- (void)hookMessageTextFieldPasteAction
{
void (^textFieldDidPasteBlock)(id receiver, id sender) = ^(id receiver, id sender)
{
NSLog(#"paste hook");
};
[self.messageTextField respondsToSelector:#selector(paste:) withKey:nil usingBlock:textFieldDidPasteBlock];
}
Yes your above code for paste is correct according to Apple's Documentation which refers to it here.
- (void)paste:(id)sender
I suspect you are implementing it in the wrong file. You should be implementing it in a file that is part of the 1st Responder chain. Have you subclassed the UITextView or are you using a vanilla one in your ViewController?
Hmmm I think the problem is that you may need to make your UITextView subclass become the delegate in order for the delegate method to work, because it's not by the looks of things. I'll try to find how i did that before.
Okay think i found it. I think you need to do this on your subclassed UITextField class:
#interface mySpecialTextFieldClass : NSObject <UITextFieldDelegate>
{
}
Adding that onto the end should work, give it a try!
What it does is makes your subclass become an object of a type that the delegate can send a notification to...it's polymorphism, unless someone wants to correct me here :)
One last thing to try John, in the ViewController which contains the IBOutlet to the UITextView, try calling this method on the instance of the UITextView:
[myUITextView setDelegate:self];
Just to throw something completely random in there try setting it to become first responder.
[myUITextView becomeFirstResponder];
This is called programming in the dark kiddies! And is a very bad way to program, but I admit I do it and sometimes it pays off :P lol.
i am trying to get a subview to become firstResponder. my understanding is that this is done in its viewDidAppear method, like so:
- (void)viewDidAppear {
[self becomeFirstResponder];
}
while overriding canBecomeFirstResponder to return YES:
- (BOOL)canBecomeFirstResponder {
return YES;
}
however, when i insert the subview in its parent view's viewDidLoad method:
- (void)viewDidLoad {
subViewController = [[SubViewController alloc] init];
[self.view insertSubview: subViewController.view atIndex: 0];
[subViewController viewDidAppear: NO];
[super viewDidLoad];
}
(i call viewDidAppear manually, because it does not get triggered automatically), the subview does not become firstResponder.
why does the subview not become firstResponder? and how can i make it firstResponder?
thanks,
mbotta
btw, this is a rewrite of my original question:
i am trying to build an iphone app where a rootviewcontroller object manages two subviews, one of which should react to a user shaking his iphone.
after some digging, i concluded the subview must be made firstResponder in its view controller's viewDidAppear method. moreover, the canBecomeFirstResponder method should be modified to return YES.
so here's what happens: i instantiate the rootviewcontroller in the app delegate. in its viewDidLoad method, i tell it to addSubView firstViewController. all of this works just beautifully.
however, firstViewController does not react to any shaking. i sprinkled some NSLogs around and found that while we DO tell firstViewController in canBecomeFirstResponder to return YES, and while we DO tell it to [self becomeFirstResponder] in viewDidAppear, in actual fact, it is not the firstResponder.
so, my questions are:
1) does a subview actually need to be firstResponder in order to react to shaking?
a) if not, how does one make a subview react without being firstResponder?
2) how does one make a subview firstResponder?
what makes this interesting is that if i perform the same sequence (canBecomeFirstResponder, [self firstResponder], motionBegan:) in a different project with only one view controller, it all works flawlessly. clearly, i must be hitting a design flaw of my own making.
thanks,
mbotta
Not 100% sure, but this could be your problem. If we could see the offending methods it might be easier.
From the Event Handling Best Practices (emphasis added by me):
If you handle events in a subclass of
UIView, UIViewController, or (in rare
cases) UIResponder,
You should implement all of the event-handling methods (even if it is
a null implementation).
Do not call the superclass implementation of the methods.
If you call the superclass methods the events are probably getting passed along to the nextResponder.
EDIT
The Event Handling Best Practices link above is dead. I couldn't find that pull quote anywhere, but Event Handling Guide for UIKit Apps seems to be the most relevant.