Loading a custom input view into a UITextField, I can arbitrarily change the keyboard type of the standard keyboard between UIKeyboardTypeAlphabet and UIKeyboardTypeNumberPad. Just call something like:
[editingField setKeyboardType:UIKeyboardTypeNumberPad];
[editingField reloadInputViews];
And viola! There is your number pad.
Without changing this block of code, but just making editingField a UITextView instead of a UITextField, it no longer works. According to the docs, these are both compliant with the UITextInput and UITextInputTraits protocols.
It is worth mentioning that the above code actually does work, but only after the user leaves the textView in question and later reselects it. It is almost like reloadInputViews does nothing, and then the textView loads its input views when it becomeFirstResponder.
I have tried all sorts of performSelector: etc and cannot force the issue. Any ideas? How do you make UITextView obey reloadInputViews and dynamically change its inputView?
Are you setting inputView of UITextView to nil before calling?
[editingField setKeyboardType:UIKeyboardTypeNumberPad];
[editingField reloadInputViews];
Related
How do I make a UITextView behave like a UITextField or maybe how to make a UITextField appear like this, same with the photo, i've searched a lot about making UITextField into multiple lines but i can't seem to get how they did it, is there any method that is much simpler,
I also tried putting a UITextView and then sending it at back and putting at top a UITextField and in the viewDidLoad I did self.commentTextField.frame = self.commentsTextView.frame; , i thought it would make the UITextField like a UITextView.
I want that when I start editing this
- (void)textFieldDidBeginEditing:(UITextView *)textField;
delegate would detect that Im editing the UITextField because I can't seem to detect when Im editing the UITextView
As others said, use UITextView instead of UITextField, just remebering of setting editable to YES.
And about the delegate, - (void)textFieldDidBeginEditing:(UITextView *)textField; is a method of UITextFieldDelegate , and, as the name of the protocol says, it will only work for UITextFields. Changing the type of the parameters will have no effect.
What you may want is the similar textViewDidBeginEditing: , of UITextViewDelegate. Implement this new protocol, just don't forgetting to set the delegate correctly.
self.textView.delegate = self;
UITextField is one line only, you need to use UITextView instead, and if you are looking for rounded corners you can use:
self.commentTextField.clipsToBounds = YES;
self.commentTextField.layer.cornerRadius = 10.0f;
I suggest to check this question:
How to create a multiline UITextfield?
I am trying to add a couple characters that are inconveniently located in the normal keyboard, and place them in a toolbar so that the user can use them just like normal keys.
Does anyone have a useable way to do this?
I found an article explaining how to do this by simulating a "Paste" operation, (remove pasteboard contents, replace with my character, paste into field, return original pasteboard contents) but my trouble is that I'm trying to do this with a UISearchBar, which seems to have no paste selector.
Update
I found a lead:
UIKIT_CLASS_AVAILABLE(2_0) #interface UISearchBar : UIView {
#private
UITextField *_searchField;
Since it is documented that there's a UITextField in a search bar, if I were to root through the searchbar's subviews and locate said text field, (assuming with 99% certainty that the text field has a delegate) would it make sense that I could "steal" the text field and make my class the delegate, then forward the messages to the original delegate once I'm done with them?
This is definitely tricky. UISearchBar doesn't give you inputAccessoryView and nor do you get selectedRange.
You can paste in a UISearchBar. If you want to get your tricky characters to the pasteboard, you could get a button to execute something such as:
[[UIPasteboard generalPasteboard] setString:#"[*]"];
and then get the user to use paste in the UISearchBar. Pretty awkward for the user though.
Rooting through the subviews to find the UITextField might work. If you do this, you'd need to grab the existing delegate and make yourself the delegate. Then your delegate would need to transmit messages on. The process is described in this stackoverflow question and answer. Potential challenges here: (a) the Apple implementation could change between iOS updates and even, though unlikely, change the delegate during the lifetime of the UISearchBar; (b) Apple might see this as using a private API and reject the app. (I don't have any hard evidence of (b), but it's something to consider.)
One approach might be to use the bookmark button. The UISearchBar delegate can detect this. You could use that to insert your special characters or offer up a menu of special character insertions. Of course, you won't know where the cursor is. But, depending on your use case, appending the special characters at the end might be OK. Perhaps this doesn't get you anything over a button on your interface that just appends something.
[[self searchBar] setText: [NSString stringWithFormat:#"%#[*]", [[self searchBar] text]]].)
Implementing your own search bar might be the best way to go as already suggested #hyperbole. I've done this successfully by adding a custom UITextField (with my own magnifying glass in the leftView slot etc.) and adding it as the titleView of my navigationBar. But, if I understand your question aright, that still won't be enough, as UITextField doesn't provide selectedRange and its delegate doesn't provide an equivalent of textViewDidChangeSelection:. You might have a go with a UITextView that is fixed to one line (with scrolling clamped down if required - it often seems to be).
Can't you simply set the text of the UISearchBar? Of course, the tricky part is to determine the cursor position. For that, you can register a UITapGestureRecognizer on the UISearchBar, determine the tap co-ordinates & calculate the cursor position using - (CGSize)sizeWithFont:(UIFont *)font forWidth:(CGFloat)width lineBreakMode:(UILineBreakMode)lineBreakMode or its variants.
You may also have to register a UIPanGestureRecognizer, as the user can change the cursor position by tapping, dragging & then releasing the finger.
HTH,
Akshay
My view has two UITextFields and a UISwitch. If a user is edits a textField, and then immediately touches the switch (without pressing return), the text is left as they typed it, without AutoCorrect.
If I know which textField they were typing in, I can force the autocorrect to complete by calling [textField resignFirstResponder]. But the user could be typing in either textField, so I don't know which one to call.
How can I get around this? Is there a way of detecting which textField was being used? Or something simpler I haven't thought of?
One lovely way of doing this without having to keep track of which field is active:
// This causes the current responder (eg. an input field) to resignFirstResponder and
[self.endEditing:YES];
Replace [self.view endEditing:YES] with the below one...
[[UIApplication sharedApplication] sendAction:#selector(resignFirstResponder) to:nil from:nil forEvent:nil];
The uitextfielddelegate methods are called for the textfield on which the editing is in progress. So that way you needn't be facing the problem of detecting which text field is being edited.
So implement the uitextfielddelegate methods and assign the delegate of the text field to the class where you implement the methods and handle the responses in them.
The methods which you should be interested in are:
textFieldDidEndEditing:
Tells the delegate that editing stopped for the specified text field.
- (void)textFieldDidEndEditing:(UITextField *)textField
Parameters
textField
The text field for which editing ended.
Discussion
This method is called after the text field resigns its first responder status. You can use this method to update your delegate’s state information. For example, you might use this method to hide overlay views that should be visible only while editing.
Implementation of this method by the delegate is optional.
Availability
Available in iOS 2.0 and later.
Declared In
UITextField.h
You may keep track yourself which one is the current one, by using the textFieldDidBeginEditing delegate.
I'm trying to implement the answer to this SO question. The problem is: -[drawTextInRect] is apparently not called, and setting the shadow in -[drawRect] doesn't make the UITextField's text shadowed.
Another weird thing is that even if my subclass implementations of -[drawTextInRect] and -[drawRect] are completely empty (not even a call to super), the textfield's text is drawn.
This is a bug in the UITextField API documentation. The documentation indicates that overriding drawTextInRect: can be used to customize behaviour. This is not the case.
In fact, drawTextInRect: will never be called on an UITextField (drawPlaceholderInRect: will be called neither by the way).
See also http://discussions.apple.com/thread.jspa?threadID=1727596.
Overriding the method on UILabel works though.
I guess the method you are looking for is:
- (CGRect)textRectForBounds:(CGRect)bounds
or possibly
- (CGRect)editingRectForBounds:(CGRect)bounds
I note that -[drawTextInRect] is called once when the UITextField loses focus. Not what I wanted.
UITextField does not respond to a - drawTextInRect: message. The code on the page you reference subclasses a UILabel not a UITextField, which is why it didn't work for you.
If you don't call super, the compiler might be removing the method during optimization of your code. Effectively meaning that UILabel's implementation is getting called.
Update:
If you are using a nib to create the textfield, be sure you have set the class of the textfield in the nib to your custom subclass, otherwise your custom code will not be called.
I'm currently developing an OpenGL ES game for the iPhone and iPod touch.
I was wondering how I can easily pull up the UIKeyboard?
Is there an official, documented possibility to pull up a UIKeyboard without using a UITextField of UITextView?
If you subclass UIResponder, and declare the UIKeyInput protocol, the keyboard will appear when you become the firstResponder.
See the UIKeyInput protocol here.
One thing that tripped me up is that you'll need to override the canBecomeFirstResponder message.
It's not "officially" possible - you can't access the UIKeyboard object at all while staying within Apple's guidelines.
Creating an invisible UITextField, then calling [textField becomeFirstResponder] would do the job - you could even subclass UITextField first, then override the delegate method textField:shouldChangeCharactersInRange: to redirect the text input to where you want it to go.
It is indeed possible. I had myself struggled a lot with this. UIKeyInput protocol can be used to pull a keyboard without using a UITextField or UITextView. However it is only available in iOS 3.2 and above. Here is a tutorial on that.
Hope that helps.
I displayed the keyboard without any visible UITextField by positioning my textfield's frame out of the visible screen:
#define TEXT_FRAME -50,-50,0,0
self.textField = [[UITextField alloc] initWithFrame:CGRectMake(TEXT_FRAME)];
When I set the "first responder" the keyboard becomes visible without any visible input area:
// show the keyboard
[self.textField becomeFirstResponder];
I later dropped the idea. However, I don't know its conformance to the Apple guidelines.
I haven't tried it but http://www.cocoadev.com/index.pl?UIKeyboard shows some code that looks like it should work.