Has anyone run across this warning message building for the iPhone?
More importantly do you understand how to fix it?
"unsupported configuration data detection and editable"
It's seems to be the UITextView that is complaining.
Here's a screenshot.
The problem is that you have that textview set both to editable + to detect/autolink phone numbers, events, addresses, etc. a text area can either be editable and not detect/autolink text, or it can autolink text but not be editable.
Your settings for that textview should look like:
or
but not like:
I think in your scenario, the text input is only used to input text, nothing more. Then when it get's presented back, the "presenting text view" will take care of detecting the potential information... dates, events, etc.
To be more precise : in a simple app scenario, a user types in some text (let's say an event input text view - with no detection necessary at this point). Then when it get's eventually presented back to him or another user (let's say the detail view of the event), the text will be presented back in a "non-editable" text view that in turn will be able to have detections.
I know this question is a little old, but this is how I resolved it;
In Interface Builder I have Links Detection selected, and Editable Behaviour not selected.
Then, in my ViewController, I implemented the UITextView - (BOOL)textViewShouldBeginEditing:(UITextView *)textView { } delegate method and return NO.
It removed the warning and prevents the user from being able to edit the UITextView's content.
Related
I have a problem with how VoiceOver announces my custom UITextInput while it has the keyboard focus: When the accessibility focus is moved to the UITextInput view by swiping left/right the UITextInput is correctly announced by VoiceOver and I am hearing something like Text field, is editing, <content of text input>, character mode, insertion point at end.
However, if I move the accessibility focus to the UITextInput by tapping on it, VoiceOver says empty line, which is not correct.
I would expect VoiceOver to make the exact same announcement regardless of how the UITextInput got the accessibility focus.
Any ideas what might be the cause of this strange behavior?
To mark up a text field you need to take advantage of a few different properties. First, the "Text field" part you can only get by having your custom control extend the UITextFIeld class. That's the only way you can get that announcement at the beginning without effecting the read out of other things. You could append this to the label. Here are the properties I would recommend for your custom text editor.
Preferred Markup
ClassType: Subclass of UITextField (Probably the most important piece)
AccessibilityLabel: The thing the entered text represents (Ex: Password, Username, etc).
AccessibilityValue: The entered text.
AccessibilityHint: "Some non critical information, that shares some details about what the entered information will be used for."
AccessibilityTraits: (NOT Static Text Trait)
Note that the hint isn't crucial information. Hints are frequently ignored, and just contain useful clarifying information.
Aleternate markup (NOT RECOMMENDED)
ClassType: Subclass of ????
AccessibilityLabel: Text field, $EditingState, $EnteredText, $InsertionPoint
AccessibilityValue: nil
AccessibilityHint: nil
AccessibilityTraits: StaticText (Weird, but if you're including role information yourself, we want the trait of static text on an editable text field, to avoid VoiceOver being smart, including it, and duplicating role information in the announcement... is this starting to feel like a hack yet???)
This is honestly a terrible idea, you really should just have your TextField inherit from the system UITextField and get all of that stuff for free, but if you must, this is how you wold achieve... similar behavior without doing so. I say similar because there are a few things you CANNOT replicate in a custom control.
keyboard type ("character mode") is more painful for you to grab than the system, and I recommend omitting in the custom case. The keyboard doesn't have to respect your requests for mode changes (custom keyboards and such), you can get into trouble and confuse users attempting to share this based on your application's settings. The system is the only thing that can get this right in all scenarios.
Inflection. By doing this the custom way you will lose the style and inflection from VoiceOver. The pauses between the Label and the Entered Text. The lower voice that is read when the placeholder text is read out, etc. You can add commas to your AccessibilityLabel to somewhat replicate some of this, but ultimately, your custom control will always sound a little "off" to a VoiceOver user... unless your custom view extends UITextField...
I would like to add "more info" collapsible accordion into my error alert view. So it will expand with additional information about the err after user presses it. And of course it will animate the size of error alert too. How it can be done? Maybe there is already existing solution for what I need?
Thanks a lot!
The standard UIAlertView does not allow this. You'll have to make your own view that mimicks the appearance of an alert view (using a UIVisualEffectView and possibly even a UIInterpolatingMotionEffect if you really want it to look like the real thing). Takes a fair but of work, especially if you want to support older iOS versions. And of course with every new iOS version that changes the appearance of alerts, you'll have to update the code. You might be better off just going with a completely different appearance unique to your app.
Once you have made that custom view, you can add the extra field as a hidden text field. When the triangle button is pressed, you set the height of that hidden field to 0, unhide it, then animate the height of the text field and the height of the containing view to their new values.
Try this custom alert view
https://github.com/wimagguc/ios-custom-alertview
You can add whatever animation you want.
I'm having an issue. I am using the Hakawai framework in an app so that I can have mention support (#username).
The issue I've run into is that the textfield I am using is not registering the case where there is no text and a user types an emoji into the textview. As we are using HKWTextView, I believe the textViewShouldChangeTextInRange delegate method is never called, even if implemented. The only replacement I can think to use is :
- (void)textView:(HKWTextView *)textView didChangeAttributedTextTo:(NSAttributedString *)newText
originalText:(NSAttributedString *)originalText
originalRange:(NSRange)originalRange;
in HKWTextView, but that's still not picking up on emojis being typed in when no other text has.
The functionality I would like is:
- Text view is empty
- user types in anything, emoji included
- textview width shortens, "Post" button appears.
Right now, typing emojis into the empty text view will not make the post button appear. However, it's worth mentioning that once the emojis are typed in, if there is more than one, deleting one of them WILL make the post button appear. I'm at a bit of a loss here.
I found the answer to this - It turns out that HKWTextView does some rewiring of the UITextView delegate methods that are fired. Try handling the input in the UITextView delegate method textViewDidChangeSelection. That method will be fired when an emoji is typed.
How to show a custom keyboard and Input Accessory View for a editable UIWebView for iOS7 and up.
i.e: How can i set and make use a value from [UIWebView setInputView:] and [UIWebView setInputAccessoryView:]
It would be helpful to understand what you're trying to do? You can either be trying to force a specific type of keyboard such as numeric, email, etc. that will use the keyboard the user has explicitly installed on their device (or the system one).
In order to do this, you can reference this apple doc which shows you the 'type' attribute to add to an tag.
Otherwise you are asking about loading a custom keyboard that you have created from the webview. The app developer in me screams, "you should NEVER do this." If you're content is generic enough to merit putting into a webview, than it is certainly not worth loading a custom keyboard.
If you realllly need to do this, you can set keyboardDisplayRequiresUserAction to NO, then use custom javascript to request the app to perform a native function, then drop a uitextfield or uitextview directly overtop the html input field and set a custom input view on the native control. There are an obscene amount of problems with following this approach, and I sincerely hope you
Are you trying to customize the ios keyboard or you want to show an HTML keyboard?
In the first case you can look at this link: link
In the second case you can just google for it, this is the first result searching for "html keyboard".
Good luck
I believe there is no way to do this as of now. Hence, my current approach is to use a custom view below the keyboard and hide the keyboard and show the keyboard as required.
This is one of those "it was working a while ago" troubleshooting efforts.
I'm working on the document preview view controller, in which is a scroll view, which itself contains subclasses of UIView that represent each document. I'm modeling this pretty closely to how Keynote handles its document preview, except I build my scroll view horizontally and with paging. But the standard user experience is present: Long press on a document icon causes all document icons to start jiggling, nab bar has + button and Edit button, etc.
The issue at hand is that when you tap on the name of a document, I hide all the others, move the one being edited front and center, build a new text edit field, add it as a subview atop the real name label, and set it as first responder; but the
[editNameTextField setClearButtonMode:UITextFieldViewModeWhileEditing];
while correctly showing in the edit field is not taking any action when the user taps on the clear button.
I can't figure out what I may have done to cause this to not work -- it had been!
My first thought was that somehow my instance of this subclass is no longer the delegate for this text edit field. To try and confirm/deny that, I usurped a tap on the image view of the document preview to compare the delegate property to self, and it passes.
if (editNameTextField) {
NSLog(#"editNameTextField is still active");
if ([editNameTextField.delegate isEqual:self]) {
NSLog(#"we're still the delegate for the editNameTextField");
}
}
Editing the text within the edit field works fine. Pressing the Return/Done key correctly sends the delegate message textFieldShouldReturn:
While investigating this I implemented the delegate method textFieldShouldClear: just to write a log message if the method gets called (and return YES of course). It never gets called.
My next thought was that perhaps a subview had covered up the area where the clear button sits. So I implemented textFieldShouldBeginEditing: and used the opportunity to bring my the text field to the front. That didn't change anything either. I set a debugger breakpoint there to play a sound when it was called, and it got called, so I know my text edit field is frontmost.
I have only one troubleshooting strategy remaining: Go backwards through snap shots until it starts working again. Before doing that I thought I'd see if any of the more experienced folks out here have any suggestions of what to try next.
Where are you adding the textfield? As a subview of the scrollView? If you added the textfield and it is out of bounds of its parent view it won't receive any touches.
You can try and not call becomeFirstResponder and see if clicking it will show keyboard. Another possible error might be that the parent view of the UITextField has userInteractionEnabled = NO.
Without seeing more code I'm afraid I can not offer more solutions.