Question

I am getting an interesting warning at build time (iPhone simulator) that gives the following:

EditView.xib:35:0 UITextView does not support data detectors when the text view is editable.

This is basically non existent on google and I would like to remove it.

My editview.xib has a textview where I write notes into it. Is there any more info that is needed?

Was it helpful?

Solution

I was seeing this warning as well. Here's how I fixed it:

In the xib file in Interface Builder, select your text view, and bring up the attributes inspector. Make sure that "Detects Phone numbers" and "Detects Links" are both UNCHECKED.

I had "Detects Links" checked, and turns out that's what was causing the warning. Basically, if the textview is editable, you don't want these auto-detect features turned on.

OTHER TIPS

I have four different Xibs with similar TextViews that are used for notes as well. I was getting the same warnings. The suggestion to disable the "Detects Phone Numbers" and "Detects Links" does removes the warnings. However, I wanted my users to still have the ability to use the detectors in my notes.

This is how I solved the issue in my app:

  1. In IB: I deselected the two properties for the TextView. -(which does stop the build warnings).

  2. In my - (void)viewDidLoad { I set the properties of the textView to the following: myTextView.dataDetectorTypes = UIDataDetectorTypeAll; which enables the data detectors of all types (phone numbers and url addresses).

  3. In my View Controller's: -(void)textViewDidBeginEditing:(UITextView *)sender { method, I turned the data detectors back OFF using: myTextView.dataDetectorTypes = UIDataDetectorTypeNone

  4. Then taking advantage of the -(void)textViewDidEndEditing:(UITextView *)sender { method, I turned them back ON using: myTextView.dataDetectorTypes = UIDataDetectorTypeAll;

This method disables the data detectors when the user is editing the UITextView and turns the data detectors back ON when the user is finished editing. This Fix allowed for selection of the phone numbers and URL from within the textView, so that I did not loose the function.


I found the following in the Apple Docs on the DataDetectors for UITextView: after playing around with the UITextView for a while, hope it helps.

UIDataDetectorTypes:

Defines the types of information that can be detected in text-based content.

Types:

  • UIDataDetectorTypePhoneNumber;
  • UIDataDetectorTypeLink;
  • UIDataDetectorTypeNone;
  • UIDataDetectorTypeAll;


Update: 11-5-2010;

Extra Note: Data detectors are not permitted if UITextView is "Editable", because there would be too many variables to track users changes to text as well as touches with trying to execute phone call or links.

Solution: Load the TextView with self.textView.editable = NO; and set you UIDataDetector's based on the types I listed above. This way if the user wants to "select" web address or phone number etc, the delegate can handle. When you need your user to edit the textView, then turn ON the self.textView.editing = YES; & remove your UIDataDetectors accordingly. This should assure no errors or warnings during compiling.

Special Consideration: Be sure to first remove the datadectors when re-enabling, then enable "editing = YES;"...The order is important no to enable editing if UIdatadetectors are still assigned.

Therefore, the sequence order should be something like this...

  • To Edit textView: 1. remove data detectors, 2. then enable editing = YES.

  • To Use DataDetectors: 1. Disable Editing = NO; 2. then add data detectors.

So Wordy!

textView.editable = NO;
textView.dataDetectorTypes = UIDataDetectorTypeAll;

the URL address must start with "http://", otherwise the textview cannot detect it.

I thought about trying to use a Tap-Gesture-Recognizer with "delaysTouchesBegan = YES" and "cancelsTouchesInView = NO"

It is still quite easy to solve!

Load view with editable disabled as well as UIDataDetectorTypeAll or the types of links you want to detect. Then add a GestureRecognizer:

UITapGestureRecognizer *recognizer = [[UITapGestureRecognizer alloc] initWithTarget:self
                                                                             action:@selector(editTextRecognizerTabbed:)];
recognizer.delegate = self;
recognizer.numberOfTapsRequired = 1;
[self.textViewNotes addGestureRecognizer:recognizer];

So you can change settings within this method:

- (void) editTextRecognizerTabbed:(UITapGestureRecognizer *) aRecognizer;
{
    self.textViewNotes.dataDetectorTypes = UIDataDetectorTypeNone;
    self.textViewNotes.editable = YES;
    [self.textViewNotes becomeFirstResponder];
}

And at least you have to change the edit and detections settings back after user has finished the text input:

- (void)textViewDidEndEditing:(UITextView *)textView;
{
    self.textViewNotes.editable = YES;
    self.textViewNotes.dataDetectorTypes = UIDataDetectorTypeAll;
}

works lika a charm!

Data detectors for the UITextView would be for copy and paste. Since you are setting it as editable, copy/paste shouldn't be allowed where you think paste should, but copy shouldn't.

Simplenote somehow does this on iOS 4. (There's a free/lite version in case you wanna try.)

It acts a little bit different: When tapping on one of the highlighted parts, it still starts the editing, and won't follow the link.

But when you tap-and-hold on a detected dataTpye, it shows yout the menu for calling, open the link or whatever.

Also, when tapping inside the text the editing really starts at the place you tapped. So they somehow remove the dataDectectors, enable editing AND get the touches forwarded to the editable UITextview AFTER the tap is recognized.

Any ideas how to do that?

I thought about trying to use a Tap-Gesture-Recognizer with "delaysTouchesBegan = YES" and "cancelsTouchesInView = NO"

So I can remove the dataConnectorTypes and set it editable on the action method of the recognizer, and hopefully the touches to the UITextview are delivered AFTER that.

But haven't had time to test it so far.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top