On Oct 6, 2009, at 8:21 PM, Kyle Sluder wrote: > On Tue, Oct 6, 2009 at 7:54 PM, Adam R. Maxwell <amaxw...@mac.com> 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.)
I've run into that problem when mutating a text storage where the user has something selected in the view, but I've always worked around it by setting the selected range to 0,0 beforehand (I'm thinking of a non-editable master-detail view, in particular). > 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. Graham was just using the text storage associated with the view, as I read his code, not replacing it entirely... > 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? That's a fair question; I don't have a good definition :). However, if I have a master-detail view with a non-editable textview, or am updating a text view with live output from an NSTask, I don't care if the delegate gets notified of changes (so have never seen a reason to call shouldChangeTextInRange:replacementString:). There are other situations where you might want to unconditionally replace the characters of the text storage, as well. The doc examples I've seen don't call shouldChangeTextInRange:replacementString:, but I haven't done an exhaustive search. > 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. That section discusses sshouldChangeTextInRange:replacementString: in context of "...new user actions in a text view, such as a menu action or key binding method that changes the text." The only caveat I can see for modifying the text storage is that sending beginEditing/endEditing is good practice, but not strictly necessary. Given that, I'm surprised that shouldChangeTextInRange:... would be necessary in all cases, but it wouldn't be the first time I've misread the docs.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
