Re: Suggest reasons for this crash?
Re: Suggest reasons for this crash?
- Subject: Re: Suggest reasons for this crash?
- From: "Adam R. Maxwell" <email@hidden>
- Date: Tue, 06 Oct 2009 20:46:48 -0700
On Oct 6, 2009, at 8:21 PM, Kyle Sluder wrote:
> On Tue, Oct 6, 2009 at 7:54 PM, Adam R. Maxwell <email@hidden> 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden