In Vb.net we have that sort of thing right.
However, in beginning IPhone development, by David Mark, the way the author implement removing keyboard when a user tap outside the text box is by turning the whole view into a control and then create an IBaction for that view being touch.
Why not the text box touch up outside or touch down outside? Is this the normal way?
Yes it is the normal way of doing out of focus. Or you can implement UITextFieldDelegate metod textFieldShouldReturn. Where you call resignFirstResponder for a particular text field.
Related
I have a "new message" view controller in my app (just like the system sms app) where there are two textfields, one for receivers and one for the message content. The problem is when I switch between the two textfields, the keyboard may resize (depending on the input method), and I don't get any keyboard notifications. This is rather embarrassing since the keyboard may cover the textfield, which is not what i want. How can I fix this?
thanks in advance.
You can set your controller as the delegate of your text fields and when textFieldShouldBeginEditing: or textFieldDidBeginEditing: is called, perform any necessary manipulations to your view to make sure the textField is visible.
How in the world does one get the iPhone view to zoom in on a focused UITextField? I need to tap on a text field that I want to edit, and my view should zoom in to the tapped text field and pull up the keyboard (which it already does), similar to how many Internet text fields gain focus on the iPhone. Is this some type of overlay?
I've been looking everywhere for this solution but maybe I've just got the wrong terminology. Thank you in advance.
Could be a duplicate of this StackOverflow question.
In essence, there are a number of ways, but you have to program this effect manually. A textfield is already an overlay. You can either move it, or scroll the containing view.
Please follow the following steps.
Implement the delegate method for all textfield.connect the outlet of textfield in interface builder basically it's setting the delegate property.then in delegate property you can defined the method whatever you want to implement or wanted to do functionality.
Thanks
I have a somewhat complex iOS view hierarchy. One piece of text is an editable UITextField. When the user touches it, it becomes first responder, and is editable.
Here's the rub, though: Best practice should be that a touch anywhere outside the edit control causes it to resign first responder and end editing. What's the best way of accomplishing this?
Techniques I've tried:
Use the exclusiveTouch property, which stops the user from interacting with other controls, but doesn't cause editing to end. Also disallows user from interacting with my toolbar "Done" button.
Put a see-through UIView under the text field control and on top of everything else (except the toolbar), and use touches there to end editing. This works, but I end up reparenting the text field onto this other random view which sits above my whole hierarchy, which means I have to take care of the text field's layout in multiple places, since it no longer lives in the place where it lived originally, and I have to delegate all its behavior back and forth from its "shield" view to its native home container, which has all the related logic.
Is there an elegant solution to this problem that I'm missing? I figure it must be a common design issue.
Thanks.
Tile 4 "see-thru" views around the textview to capture/ignore touches. Doesn't require modifying or "lifting" the textview, and can be added to the parent view in a fairly modular way.
You can't mask a region without knowing what that mask will cover and what the mask will not cover. So any solution will require enough reach to gather both of those bounds. Either pass the text rect up, or the view rect/region to be disabled down, or both to something in-between. The controller for the stuff to be covered seems as good a place as any to consolidate both rects or regions, if not the controller for the text view.
The nub of the issue is what constitutes "best practice". The fact that the keyboard remains unless the user dismisses it is deliberate. For example, many apps need the user to be able to tap a button while still working in a text field.
The keyboard has a Return button. "Best practice" is to respond to the user tapping that button by resigning first responder. Otherwise, you should leave the keyboard there, since that's what the user expects.
However, if you insist on doing it your way, there's a simple solution: put a UITapGestureRecognizer on the background view. Its handler will be triggered if the user taps on the background or on any button or similar in the interface. So, presuming you have kept a record of what the first responder is, you can send resignFirstResponder to the first responder in the tap gesture recognizer's handler.
If you change your base view to a UIControl you can add an IBAction to that layer that resigns your text field as first responder.
Also, if you have multiple touch events, make sure they each becomeFirstResponder when touched.
I'd love to have some more details to qualify my explanations xD
I'd like to create a UITextView that you can tap anywhere within it and start typing at that location. The default behavior of the control is that typing starts where the last character ended. So, if I had a UITextView with no text in it and tap in the middle of the control, I'd like typing to start there--not in the upper left.
What is the best way to implement this behavior? I've considered making the default text value of the view to be 3000 space characters or something similar, but this seems like not an elegant solution. Suggestions?
I suggest deriving from UITextView to create a custom view that handles taps. You'll want to override the following methods, probably:
touchesBegan:withEvent
touchesMoved:withEvent
touchesEnded:withEvent
touchesCancelled:withEvent
Make sure the userInteractionEnabled property has a default value of YES. Override hitTest:withEvent and pointInside:withEvent to figure out where in your view the user tapped.
Be sure and read the Responding to Events section in the View Programming Guide for iOS, and also see the Event Handling Guide for iOS for more details.
Anyway, once you figure out where the user touched, you can modify the text or reposition the karat as appropriate.
Is it known how to get the keypad interface from the Phone and Skype apps? This is distinct from the modal keypad view that appears when a UITextField becomes the first responder.
Is this just a UIView that the developers of Skype laid out themselves in IB, complete with custom graphics to get the square shape of each button? Or is there some standard Cocoa Touch way to do it?
This isn't something that Cocoa Touch provides out of the box, no. I would imagine that the iPhone keypad is a set of UIButton objects arranged like a keypad and using custom graphics to get the visual appearance. This should be fairly easy to do in Interface Builder.
You may be looking for UIKeyboardType in the protocol UITextInputTraits, which is implemented by UITextField etc.. See the documentation at that link.
I was getting confused by your question too. I'm not aware of any but seeing as you would need somewhere to type in anyway wouldn't it be better to make the UITextField active on viewWillAppear and turn off touches on the rest of the view hence showing the keypad like the phone app?