Always send shouldChangeTextInRange:... ?
Always send shouldChangeTextInRange:... ?
- Subject: Always send shouldChangeTextInRange:... ?
- From: Fritz Anderson <email@hidden>
- Date: Fri, 6 Feb 2004 14:31:57 -0600
I'm building a terminal emulator which uses the Cocoa text system to
maintain the screen content for modeling and display.
The text storage changes only in response to input from the remote
host, whether it's character insertions, block deletions, etc.. I've
been bracketing all these operations with beginEditing and endEditing,
on the understanding that those calls nest, and that using them puts
off necessary overhead until the last endEditing message.
Recent cocoa-dev messages made me aware of the NSTextView messages
shouldChangeTextInRange:replacementString: and didChangeText. I haven't
been calling them, and I wonder if I must. Specifically,
- Are they necessary to the proper and efficient functioning of the
text system, as are begin/endEditing? That is, is it an affirmative bug
not to call them? I don't see any bugs or deficiencies in the
application that seem to come from the omission.
- My own code doesn't rely on any delegation or notifications from the
text system. Does that make the calls omissible?
- What I've read seems to imply that shouldChange... and didChange...
are most relevant to the effects of _user_ edits to the text. The
changes to my text storage, as I say, are all autonomous and not (for
instance) refusable or undoable. Do the calls just add infrastructure
for functionality I don't use?
- If I do use these messages, how bad is it that I can almost never
supply offsets and replacement strings in advance (or would have to
compute both in time-critical code)? The docs say
shouldChangeTextInRange: NSMakeRange(NSNotFound, 0) replacementString:
nil is acceptable, but what does it cost to omit the information?
- If I do use these messages, can I nest them, as I nest beginEditing
and endEditing? Inability to nest will... require serious ingenuity on
my part.
-- F
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.