I display a UITextView that I want the user to be able to copy from but not edit. There must be no keyboard present on the screen during the copy.
If I prevent first responder then the keyboard stays hidden. However this also prevents processing of events from touches that would allow a copy interaction. It also has to be editable to process touches as far as I know.
Is there an easy way to achieve this; a read-only, copy-only, no-keyboard UITextView? The docs are very terse on what "editable" guarantees, requires, and how is changes behavior.
Have you tried setEditable: NO? I know you say the docs don't describe it much, but they do say that it controls whether the receiver is editable. Did you try?
You've tried that, and the answer is to set editable to NO.
Related
Good Afternoon/Evening/Morning Folks,
I recently encountered a discussion with another developer on dismissing a UIPickerView. We work on a legacy enterprise application that had a lot of issues and was written very poorly (among other things). Since then, we revamped and fixed a lot of bugs with this program, strictly adhering to Apple's Human Interface Guidelines as much as possible while keeping to original requirements.
We seem to have a difference in opinion as Human Interface Guidelines do not really go into any detail about picker views. We implemented our new UIPickerView with a "Done," Button to confirm a selected value to be placed in a UITextField. Screen's input would be locked until they selected a value or clicked done.
Legacy application prior to our changes allowed users to utilize a done button but also by way of tapping a value selected in a picker. In addition, legacy application would also show selected UIPickerView value in UITextField prior to selection, wiping out original contents , if any was selected prior to opening a UIPickerView.
So, What is correct way to implement a UIPickerView per common practice or Strict Apple Documentation (if any exists). What is common practice?
Sorry, I cannot post any screen shots or code snippets due to business process reasons. I will do my best to explain if any questions arise.
Thanks,
We can figure this out through apps designed by Apple. Here are two examples
1. Contacts
Find a contact person in the Contacts app and set birthday. The picker shows up. While you are dragging the pickers, it does not set value to the text field. It happens only when you release the wheel. There is no Done button to hide the picker it self. To dismiss it, you can either click on the done button on navigation bar to end editing for the whole page, or click on another text field which pops a different keyboard.
2.Setting - Date&Time
Basically the same as Contacts app. Here you cannot even dismiss the picker.
I am working on an app that uses voice commands to maneuver through text fields. What I need to do is translate the voice command into a touch event on the keyboard. Specifically I need to access the tab key and the return key. The user will not be using the keyboard in this app. I am having a difficult time finding a way to get this done. I know how to convert the voice commands into something that I can use, but I still need to apply that to the keyboard commands. I have researched this extensively and I get what I think are bits and pieces of what I really need, but nothing is connecting the dots for me.
You don't need the keyboard to navigate text fields. You just need to modify the first responder. There unfortunately isn't an easy way to get the current first responder, but you can search for it.
Once you have the first responder, you can move to the next field like this:
[[field nextResponder] becomeFirstResponder];
If you are trying to do this in a very general way, you should first call canBecomeFirstResponder and handle situations where there there are no available first responders and other corner cases, but this generally isn't needed for very simple interfaces.
If you want to manage "enter" in order to end editing and dismiss the keyboard, you can call endEditing: on the superview.
You can modify text without the keyboard by replacing the text property.
I have a part on my app that I show the users, the files they have created and have stored inside the app's directory. I want to allow the users to rename the files.
I am wondering of doing this:
The user selects a file
The user taps on the RENAME button.
An alertview pops showing the old name and having a textview where the user can type the new name.
My question is: is this blessed by Apple? This sounds like a hack to the alertview.
Will the app be approved?
I googled around and I saw mixed opinions about that.
thanks
Generally I think the correct HIG-happy UI would be a UITableView with the list of of files. The user taps and Edit button and the page rows become editable, allowing you to delete a row/file (with a verification alert) and a disclosure arrow that pushes a detail view where you can change the name.
An alternative, though not HIG-friendly, is displaying the file name in a UITextField where the borderStyle set to UITextBorderStyleNone and the enabled set to NO. When the user taps the Rename button you change the borderStyle to UITextBorderStyleRoundedRect and enabled set to YES, setting the firstResponder to the text field so the cursor is flashing inside the textField. You'd need OK and Cancel buttons.
Or you could add a text field to the UIAlertView, also against the HIG but perhaps better.
I don't know if the property alertViewStyle was available when you make this question but searching to resolve this problem for me, I found that setting this property with UIAlertViewStylePlainTextInput resolve your problem.
Yes it is in iPhone sdk alertBox, alertBox can have the textField in which you rename the file.
check this link
for making such kind of stuff. No problem in accepting your app
You could either subclass UIAletView and add your own initWithTitle:message:...etc. method, as outlined in this tutorial, or use the undocumented [alert addTextFieldWithValue:#"" label:nil]; method, which is easier but may cause Apple to reject your app.
I have an application that allows the user to edit multiple text fields and views. Rather than mess around raising each view to the top when the keyboard is active, I decided to instead make one textView for editing and hide/show it when input is needed, then transfer the data when it is done. To move focus to the new textView, I call its becomeFirstResponder method, and lo and behold, the cursor goes to the right place. However if I use this method, the iPhone keyboard does not appear. I have no idea why. Can anyone explain, and tell me how to make the keyboard appear? All the other questions I've looked at seem to indicate that setting becomeFirstResponder for a textView ought to make the keyboard come up.
-Ash
Is Hardware -> Simulate Hardware Keyboard enabled?
Are you doing this whole thing programatically or using Interface Builder as well?
If so are the IB connections setup right?
I have an application I'm working on, and I need the user to be able to add new "Shows", "Movements" and "Dots." These are all represented by classes. At the root of the application, all the shows are shown, the user can click on the show, see the movement in that show, then tap on a movement and see the dots in the movement. It works beautifully.
Now, I need the user to be able to add and edit these instances of these classes. The way I am thinking this will work is when the user clicks on the "Add Show" button (Or the "Add Movement", etc) a new view will be pushed onto the Navigation Controller. This works. When the button is pressed, a new instance of the show class is created, and passed to the new view controller. This also works. If the user wants to edit the show, then they will hit the edit button for the row, and the instance of the class (which already exists) will be passed to new view controller, and the user will be able to edit it (It should use the same view controller for adding and editing)
My question is, in the examples I have seen, it is always really dirty to create the editing view. The edit view is a table view with each row having some sort of control. Usually it is a UITextField, but it may be a slider, and it may be one where another view is popped, and the user needs to check one value. (This is similar to the address book application when adding and editing a contact)
Is there any way that is cleaner than just manually going in and creating a bunch of arrays to hold what custom table view cells need to be at what row? This gets very messy, very fast. I can do it this way, I just was wondering if there is a better, possibly faster way.
To my knowledge there's no structural solution to solve this. I'm afraid managing the cells with child UITextField or other controls yourself is the only method. This indeed gets dirty and painful very fast, I certainly feel your pain.
Although it doesn't exist, it would be very convenient if Apple added out of the box editing cells to the SDK, similar to the different normal cell styles. I haven't come across an open source project that addresses this issue, but it might exist.
If you do find a better/cleaner method to handle these situations, be sure to ping back.
as far as i know, editing mode is the only way to make the changes you describe (if i understood correctly). I agree that it doesn't seem like the most elegant approach.
http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/TableView_iPhone/ManageInsertDeleteRow/ManageInsertDeleteRow.html#//apple_ref/doc/uid/TP40007451-CH10-SW19