Re: Suggest reasons for this crash?
Re: Suggest reasons for this crash?
- Subject: Re: Suggest reasons for this crash?
- From: Kyle Sluder <email@hidden>
- Date: Tue, 6 Oct 2009 20:21:30 -0700
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.)
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@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