On Tue, Oct 6, 2009 at 7:54 PM, Adam R. Maxwell <[email protected]> wrote: > If this is really necessary, hopefully it'll be documented, or one of the > text system guys can step in and clarify...I'd really like to know since I've > been doing this for years without calling > shouldChangeTextInRange:replacementString:.
The main problem I've found is that NSTextView is incredibly lazy. Like so lazy that if it doesn't have a text storage attached, and you call -setSelectedRange:, it does nothing. And then you hook up a zero-length text storage to it, and you crash because the text view still has a selection range of (0, 15) even you called -setSelectedRange: on it. (This is a real crash I experienced two weeks ago.) We are super paranoid about attaching and detaching text views to existing text storages. Granted, this is not a common thing to do. Most often you have a text view that is permanently associated with a text storage (word processor) or a field editor that creates and destroys temporary text storages as it edits different controls. Also, I'd ask "What is the difference between a user-initiated change and a non-user-initiated change?" If a user clicks on a Summarize Document button in your word processor, is the resultant change to the text storage not a user-initiated change? It would seem to me that the intended implementation would be a subclass of NSTextView with a -summarize: action to which said button was targeted, in which case the docs are quite clear on calling -shouldChangeTextInRange:replacementString:. But what if you move that logic to your NSDocument subclass? For what reason should you not call this method? The "Batch Editing" section seems to highlight the distinction between -[NSTextStorage beginEditing], which exists so that you don't send multiple text change notifications (and therefore multiple undo events) for what should be a single atomic mutation, and -[NSTextView shouldChangeTextInRange:replacementString:], which exists so that the text storage can set itself and its delegate up for text storage changes. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
