In iOS 7, I could change the keyboard type while it is the firstResponder (on the fly):
if (textField.text.length > 2) {
textField.keyboardType = UIKeyboardTypeNumbersAndPunctuation;
}
else
{
textField.keyboardType = UIKeyboardTypeDefault;
}
[textField reloadInputViews];
// (Omitting some efficiency stuff to keep example to bare bones)
This no longer works under Xcode 6/iOS 8. The documentations mostly reflect changes regarding custom keyboard.
Using resign/become first responder is (still) working:
[textField resignFirstResponder];
// Make keyboard change
[textField becomeFirstResponder];
But it just feels like an overkill. It's tearing and rebuilding a wall, just to change a picture on it.
There is a related post here:
UITextView does not seem to implement reloadInputViews
But it seems that the solution (in a comment) is "apparently declaring it as a UITextView instead of a UIResponder affects how it behaves during runtime. ... and it works now"
In my case it is a UITextField, and I tried to cast to UITextView just in case. No go.
I'll mention again that it is working well under iOS7 / Xcode5.
I don't really know if this is a 'beta' issue with Xcode 6, or a design change in iOS 8.
I found the same issue. It is better to check whether the textField is already the firstResponder or not.
[textField reloadInputViews]; // does not work on iOS8 !
if ([textField isFirstResponder]) {
[textField resignFirstResponder];
[textField becomeFirstResponder];
}
Not a clean way though, but it works.
I found that this works when the textfield is first responder:
[self.textField reloadInputViews];
[self.textField setText:#" "];
[self.textField setText:#""];
Related
I'm trying to create a UISwitch laid on mapView_ of Google Maps for my iOS app, but it seems not to work.
In details, I first followed instruction from google, created mapView_, then made it my viewcontroller's view:
self.view = mapView_;
Then, I created an UISwitch programmatically and added it as a subview:
mySwitch = [[UISwitch alloc] initWithFrame:CGRectMake(50, 360, 0, 0)];
[mySwitch setBackgroundColor:[UIColor clearColor]];
[mySwitch addTarget:self
action:#selector(changeSwitch:)
forControlEvents:UIControlEventTouchDown];
[mapView_ addSubview:mySwitch];
But when I touched the switch both in simulator and device, it didn't change its state from ON->OFF or OFF->ON. I even tried different UIControlEvent, such as UIControlEventValueChanged but it didn't work. To make sure that the code should work, I tried on a normal view of a normal test viewcontroller (that means, not using google maps), it worked fine!
Does anyone have any comment about this issue?
Thanks heaps!
You can work around this issue by adding both the UISwitch and the GMSMapView to a single UIView parent, instead of adding the UISwitch as a child of a GMSMapView. Yes, this means you need to position both the GMSMapView and the UISwitch.
update 2
viewDidAppear is executed twice, once before and once after, the overlay button is touched. Would a fix be to add a conditional to viewDidAppear which would return control to the calling class? If so, I would appreciated suggestions. Or maybe the very fact that viewDidAppear execute twice suggests another approach to a fix?
update 2
update 1
Maybe the problem is my usage of viewDidAppear and viewDidLoad shown below. Can anyone help, please?
- (void)viewDidAppear:(BOOL)animated
{
self.overlayViewController = [[BSsetupOverlayViewController alloc] initWithNibName:#"BSsetupOverlayViewController" bundle:nil] ;
// as a delegate we will be notified when pictures are taken and when to dismiss the image picker
self.overlayViewController.delegate = self;
[self showImagePicker:UIImagePickerControllerSourceTypeCamera];
}
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view from its nib.
}
update 1
update 0
Perhaps I was not clear that the difference between the version that does not work and the one that does is that Storyboard is used in the one that does not work. Why would a done button work without Storyboard, but not with, even though only a nib is involved with the overlay?
update 0
The UIButton here was able to dismiss the camera preview, but in my actual app, tapping the UIButton only temporarily dismisses the preview and overlay screen. Immediately the preview returns. I think the problem is with the way I am implementing the delegate to the UIImagePicker, but I may be wrong.
I have created setup.zip here which contains a sample project with the undesirable behavior.
I took this question to the North Atlanta iOS Meetup and suggested that a conditional clause might fix the problem, as I mentioned in update 2 of the question. The founder of the Meetup, Kurt Niemi, quickly showed how to do so by editing the BSsetupViewController class.
First he added a Boolean property to the interface.
#property (nonatomic, assign) BOOL alreadyDisplayed;
Second he added a clause to the viewDidAppear method.
if (self.alreadyDisplayed)
{
self.alreadyDisplayed = FALSE;
[self dismissViewControllerAnimated:NO completion:nil];
return;
}
self.alreadyDisplayed = TRUE;
And last he added a slight unnecessary clause to the viewDidLoad method.
self.alreadyDisplayed = FALSE;
I still wish these steps were unnecessary, but they seem to work.
I am having a really weird issue when testing on my 1st gen. iPad (running iOS 5).
I have a UIView that I use as a property (with retain). I nil the property in the parent view's dealloc method. Pretty basic stuff. It works perfect on my iPad 3 running iOS 6, but doesn't get released on my 1st gen.
Any ideas what might be going on?
I'm not using ARC.
If you're retaining it, you have to release it. You can't just nil the instance variable.
So if you're property looks like this:
#property (nonatomic, retain) UIView *myView;
You're dealloc would either look like this:
- (void)dealloc
{
[myView release], myView = nil;
[super dealloc];
}
Or this:
- (void)dealloc
{
[self setMyView:nil];
[super dealloc];
}
Or this:
- (void)dealloc
{
self.myView = nil;
[super dealloc];
}
And your property will properly get released--unless something else is retaining it.
So I figured this out. It seems to be a bug in the iOS 6 SDK or maybe I just don't understand it. I have a UIViewController that presents another vc via presentViewController:animated:completion: —If I dismiss the presented vc then it releases and subsequently all subviews are removed and all is well.
However, if while the presented vc is showing, I remove/destroy the parent vc, the presented vc is deallocated but, its subviews are not told to removeFromSuperview; This doesn't show up as a leak in instruments, BUT it does prevent the subviews from deallocating.
This does not happen on iOS 6, thus I suspect this is a bug in iOS 5. Everything releases/deallocates as one would expect on iOS 6.
If someone has an explanation, or a better understanding of this, I would love to reward the answer to them instead of myself.
A view controller isn't responsible for removing its view from the superview when the view controller is dealloc'ed. The view controller is just responsible for releasing its own reference to it.
For example: you can create a view controller, ask for its view, then add that view to another view and throw away the view controller. In that case, you're just using the view controller as a view builder.
I'm not sure why the behavior is different in iOS 6, but would love to know.
I am using the following code to deselect an NSTextView, as suggested here. Unfortunately, nothing at all happens. I have tried what I know to debug it, but everything seems to be working correctly, but it doesn't affect the NSTextView.
The code:
// Sets the scrolling bounds and behavior. This might be useful, but I don't know
[[textView textContainer] setContainerSize:NSMakeSize(FLT_MAX, FLT_MAX)];
[[textView textContainer] setWidthTracksTextView:FALSE];
// The code for deselecting, beginning by making sure it is actually selected (for testing only, as strange as it is)
[textView setSelectable:TRUE];
[textView setDelegate:self];
[_window makeFirstResponder:textView];
NSText *fieldEditor = [_window fieldEditor:TRUE forObject:textView];
[fieldEditor setSelectedRange:NSMakeRange([[fieldEditor string] length],0)];
[fieldEditor setNeedsDisplay:YES];
Any ideas about why this doesn't work? I am sure my outlets are set properly because I can manipulate other things, such as it's string value.
I'm not sure NSTextViews use the field editor, have you tried calling the method on the text view directly?
[textView setSelectedRange:NSMakeRange(textView.string.length, 0)];
The range location can be adjusted to move the cursor to the start or end, for example. You may also want to check to make sure something is actually selected before calling this method.
EDIT:
From your comment it sounds like you just want it to resign first responder. You can do that manually by calling [textView.window makeFirstResponder:nil];
This almost worked for me;
[textView.window makeFirstResponder:nil];
However, I had trouble setting the first responder to nil. If I set it to any other view it seems to do as you want.
[textView.window makeFirstResponder:[textView superview]];
Tested in 10.7 Lion.
I've using this approach and it works perfectly:
[textView setSelectedRange:NSMakeRange(0, 0)];
As suggested earlier setSelectedRange: will do the trick BUT!
If your goal is to completely remove the selection and the cursor too, f.e. if you subclass an NSTextView to support similar behavior like NSTextEdit has in case of firstResponder status change you should write:
- (BOOL)resignFirstResponder
{
// Invalid range location will remove cursor too
[self setSelectedRange:NSMakeRange(NSUIntegerMax, 0)];
return YES;
}
//------------------------------------------------------------------------------
- (BOOL)becomeFirstResponder
{
[self setSelectedRange:NSMakeRange(0, self.string.length)];
return YES;
}
//------------------------------------------------------------------------------
[textView setDelegate:self];
I have a feeling that one of your delegate methods is preventing things from happening. See the documentation under "Managing the selection".
As a temporary solution, just until somebody comes up with a better idea, setHidden: can be used. I am sure this is not as efficient as is recommended, but it deselects the NSTextView.
Simply toggle it twice, like so:
[textView setHidden:TRUE];
[textView setHidden:FALSE];
I have a view with a UITextField which should hide the keyboard when return is pressed.
My function is this:
- (BOOL)textFieldShouldReturn:(UITextField *)textField {
if ( textField == userPassword ) {
[textField resignFirstResponder];
}
return YES;
}
Normally the keyboard should be hidden but it stays on the screen. resignFirstResponder is correctly called. What am I missing?
I see you have the iPad tag on this. Do you happen to be presenting a modal view using UIModalPresentationFormSheet? If so, it looks like this is a limitation of the FormSheet modal presentation (either Apple is doing it intentionally for some reason, or it is a bug). See these other questions for more details:
Modal Dialog Does Not Dismiss Keyboard
Modal View Controller with keyboard on landscape iPad changes location when dismissed
There is this helpful method which allows you to dismiss the keyboard when presenting the Modal Dialog:
- (BOOL)disablesAutomaticKeyboardDismissal { return NO; }
This will override the default behavior of the modal dialog set by Apple and allow you dismiss the keyboard. It is in the UIViewController Class.
I hope this helps someone!
If you are using the Interface Builder, look if your UITextField has the delegated linked with your class.
-Select your UITextField and in your Connections look if exits one connection in Outlets->delegate. If not, conect with you File's Owner Class.
This need to be linked with your File's Owner Class. This delegate tell where to search for a method. If your are overriding a method, you need to tell where the object will search for that.
This solution worked for me after none of the above did. after calling resignFirstResponder i added a modal view & removed it.
[myTextField resignFirstResponder];
UIViewController *dummyController = [[UIViewController alloc] init];
UIView *dummy = [[UIView alloc] initWithFrame:CGRectMake(-1, -1,1,1)];
[dummyController setView:dummy];
[self presentModalViewController:dummyController animated:NO];
[dummyController dismissModalViewControllerAnimated:NO];
To deal with the bug mentioned by Brandon, you can try closing and re-opening your modal view controller as long as you still have a reference to it.
[textField resignFirstResponder];
[self dismissModalViewControllerAnimated:NO];
[self presentModalViewController:yourModalViewControllerReference animated:NO];
(where "self" should be the controller you used to originally open the modal view controller)
I was having the same problem. I realized that after connecting the delegate to the File's Owner in Interface Builder, I neglected to save in Interface Builder. Once I saved, I recompiled and the keyboard disappears correctly when hitting return.
xcode 4.5.1
Simply click control then on the textfield drag and release on the .h file
(control key+ drag)
then in the pop up menu select
connection=acton;
name= any name;
type=id;
event=did end on exit;
arguments=sender;
then click connect button
Did you remember to implement the UITextFieldDelegate protocol?
I have read so many articles about this issue, where the onscreen keyboard refuses to hide when you call resignFirstResponder, but none of the suggestions worked for me.
I'm using XCode 5 (iOS 7) and have a iPhone screen containing a couple of controls which require the onscreen keyboard, but if the user clicks on the UIButton, then I want the keyboard to disappear.
I probably wasted one full day experimenting with resignFirstResponder and adding disablesAutomaticKeyboardDismissal functions to return NO, but nothing worked. Once the onscreen keyboard appeared, I could never get it to disappear again.
But then I had a small brainwave (as I only have a small brain).
Now, when the user clicks on my UIButton, I simply disable the UITextField and UITextView controls.
- (IBAction)btnDate_Tapped:(id)sender {
// The user has clicked on the "Date" button.
self.tbClientName.enabled = NO;
self.tbComments.editable = NO;
And suddenly, the app finds it has no editable text fields needing an onscreen keyboard, and it neatly slides the keyboard out of sight.
(Relieved sigh.)
My UIButton actually makes a popup dialog appear. When the user dismisses the popup, I re-enable these two controls, so if the user taps in one of them, the keyboard will appear again.
-(void)popoverControllerDidDismissPopover:(UIPopoverController *) popoverController {
// The user has closed our popup dialog.
// We need to make our UITextField and UITextView editable again.
self.tbClientName.enabled = YES;
self.tbComments.editable = YES;
... etc...
}
Simple, isn't it !
And surprisingly, this workaround even works on UIViewControllers which appear in Modal style.
I hope this helps other XCode victims out there.
Based on your comment that it looks like focus has shifted, then I think what may be happening is that the keyboard is staying open for the next text input field. If your return key is a "Next" key, then returning YES for textFieldShouldReturn: will make the next textField the first responder, and keep the keyboard visible.
The easiest way is:
Go to your user interface builder,
select UITextField and "Control-Drag" to "Detail View Controller-Detail" and release.
The window will pop-up. Then under "Outlets" select "Delegate".
That's it. It worked for me.
if you are in UIModalPresentationFormSheet just call
- (BOOL)disablesAutomaticKeyboardDismissal
{
return NO;
}
Swift 3.0:
override var disablesAutomaticKeyboardDismissal: Bool {
get{
return false
}
set {
self.disablesAutomaticKeyboardDismissal = false
}
}
Swift 3.0
func textFieldShouldBeginEditing(_ textField: UITextField) -> Bool {
if textField == addressTextField {
textField.resignFirstResponder()
return false
}
return true
}