A question about UITextView delegate methods....

" A text view delegate responds to editing-related messages from the text view. You can use the delegate to track changes to the text itself and to the current selection".

Are you doing that?

Did you follow the link [UITextView Class Reference] and study the page/sources it is from?

Work on your understanding first and then come back to implementation.

welcome to the fuzzy world of the iPhont libraries. Unfortunately one can never tell which event stream one should be getting, because many of the standard handlers absorb events and they are swallowed up and never seen by your code. This is the black hole of both the Microsoft OS and iPhone, no actual documentation on what event streams are guaranteed, in what order or quantity. Makes program a trial and error time waster instead of a thinking game like chess.

Shnaps wrote:
textViewShouldBeginEditing and textViewDidBeginEditing are not called.

Hey Sam - I made a testbed from the View-Based App template, adding only a text view and a button to send resignFirstResponder. I'm getting all the expected delegate messages. The only anomaly is that the ShouldBegin and ShouldEndEditing methods are being called more than once, often 3 times, though never more than that.

I need to add that I'm testing on 2.1 right now, but I doubt we're looking at a 3.0 problem. There's not a peep about a similar problem on the web, so I'm guessing my results are relevant. When a delegate method is ignored, I always check for a spelling error in the signature. All the text view delegate methods are optional so the compiler won't warn you about missing methods, and there won't be any runtime warnings either. Here are the methods I used in the testbed; if you paste directly from the forum, you can be sure the signatures are correct:

#pragma mark -
#pragma mark Text View Delegate Methods
- (BOOL)textViewShouldBeginEditing:(UITextView *)textView {
 NSLog(@"textViewShouldBeginEditing");
 return YES;
}
- (void)textViewDidBeginEditing:(UITextView *)textView {
 NSLog(@"textViewDidBeginEditing");
}
- (void)textViewDidChange:(UITextView *)textView {
 NSLog(@"textViewDidChange");
}
- (void)textViewDidChangeSelection:(UITextView *)textView {
 NSLog(@"textViewDidChangeSelection");
}
- (BOOL)textViewShouldEndEditing:(UITextView *)textView {
 NSLog(@"textViewShouldEndEditing");
 return YES;
}
- (void)textViewDidEndEditing:(UITextView *)textView {
 NSLog(@"textViewDidEndEditing");
}

Here's the log for a typical run. This log is from a simulator run. The device run is correct, but the log is harder to read because I have difficulty touching once and only once in the spot I'm aiming for:

[Session started at 2009-08-15 23:25:50 -0700.]
2009-08-15 23:26:00.261 Sam[41788:20b] textViewShouldBeginEditing // 1st msg after click on text view
2009-08-15 23:26:00.296 Sam[41788:20b] textViewShouldBeginEditing
2009-08-15 23:26:00.297 Sam[41788:20b] textViewDidBeginEditing
2009-08-15 23:26:00.298 Sam[41788:20b] textViewDidChangeSelection // last msg after click on text view
2009-08-15 23:26:00.317 Sam[41788:20b] textViewDidChange // 1st back space
2009-08-15 23:26:14.085 Sam[41788:20b] textViewDidChange // 2nd back space
2009-08-15 23:26:14.556 Sam[41788:20b] textViewDidChange // 3rd back space
2009-08-15 23:26:16.967 Sam[41788:20b] textViewDidChangeSelection // 1st click in text view
2009-08-15 23:26:18.591 Sam[41788:20b] textViewDidChangeSelection // 2nd click in text view
2009-08-15 23:26:19.191 Sam[41788:20b] textViewDidChangeSelection // 3rd click in text view
2009-08-15 23:26:23.854 Sam[41788:20b] textViewShouldEndEditing // 1st msg after sending resign
2009-08-15 23:26:23.854 Sam[41788:20b] textViewShouldEndEditing
2009-08-15 23:26:23.856 Sam[41788:20b] textViewShouldEndEditing
2009-08-15 23:26:23.858 Sam[41788:20b] textViewDidEndEditing // last msg after sending resign

The DidChangeSelection message is sent for each click in the view, even if I repeatedly click in the same spot so that the caret doesn't move.

Hope that helps!
- Ray

Shnaps wrote:
... when , I marked the text for the UITextView as not editable in app's NIB, the *BeginEditing methods were not called

Ookay.. I unchecked Editable in the IB Text View Attributes panel and added a button to toggle the text view's editable property ON or OFF. Here's the controller implementation for reference:

// SamViewController.m
#import "SamViewController.h"
@implementation SamViewController
@synthesize theTextView;
@synthesize buEdit;
- (void)setEditTitle {
 if ([theTextView isEditable])
 [buEdit setTitle:@"Edit Off" forState:UIControlStateNormal];
 else
 [buEdit setTitle:@"Edit On" forState:UIControlStateNormal]; 
}
- (void)viewDidLoad {
 [super viewDidLoad];
 [self setEditTitle];
}
- (IBAction)edit {
 if ([theTextView isEditable]) {
 [theTextView resignFirstResponder];
 theTextView.editable = NO; 
 } 
 else
 theTextView.editable = YES;
 [self setEditTitle];
}
- (IBAction)done {
 [theTextView resignFirstResponder];
}
- (void)dealloc {
 [buEdit release];
 [theTextView release];
 [super dealloc];
}
#pragma mark -
#pragma mark Text View Delegate Methods
- (BOOL)textViewShouldBeginEditing:(UITextView *)textView {
 NSLog(@"textViewShouldBeginEditing");
 return YES;
}
- (void)textViewDidBeginEditing:(UITextView *)textView {
 NSLog(@"textViewDidBeginEditing");
}
- (void)textViewDidChange:(UITextView *)textView {
 NSLog(@"textViewDidChange");
}
- (void)textViewDidChangeSelection:(UITextView *)textView {
 NSLog(@"textViewDidChangeSelection");
}
- (BOOL)textViewShouldEndEditing:(UITextView *)textView {
 NSLog(@"textViewShouldEndEditing");
 return YES;
}
- (void)textViewDidEndEditing:(UITextView *)textView {
 NSLog(@"textViewDidEndEditing");
}
@end

I got results similar to your post, but on this system, those results are easily explained. I found that turning the editable property on always gave first responder status to the text view. I.e. programmatically changing theTextView.editable from NO to YES immediately brings up the keyboard and activates the caret. In this case there are no ShouldBegin or DidBeginEditing messages, and we shouldn't expect any because editing was started programmatically (i.e. the delegate is only there to customize the response to user actions). Of course after touching the "Edit On" button, a subsequent touch on the text view doesn't cause the delegate to get any BeginEditing messages, because editing has already started.

So over here, there's no indication that unchecking Editable in IB did anything unusual. In any case, if that box isn't checked, there's no way to begin editing without first setting the property programmatically.

Were you able to set the editable property to YES in code without activating the keyboard and caret? If so, I don't think I'll be able to reproduce your result. When you did your tests, is it possible you didn't consider that the keyboard and caret were already active when you expected a touch on the text view to produce BeginEditing messages?

- Ray

p.s.: You can ignore the #pragma lines. A pragma is a directive to the build system which has no effect on the source code. Sometimes a pragma is used to modify the compiler options for a certain block of code, often to turn off a particular warning. In the above example, the pragma lines are just formatting the list of methods that Xcode displays when you expand the Function Menu in the center of the Navigation Bar in an Editor window. - R