Re: Maintaining an ordered array of attributes in an NSTextStorage subclass
Re: Maintaining an ordered array of attributes in an NSTextStorage subclass
- Subject: Re: Maintaining an ordered array of attributes in an NSTextStorage subclass
- From: Keith Blount <email@hidden>
- Date: Mon, 10 Aug 2009 13:07:27 -0700 (PDT)
Many thanks again for the reply, much appreciated. -replaceCharactersInRange:withString:, -setAttributes:range: (and -addAttribute:value:range:, which also needs overriding) is in fact exactly where I'm trying to intercept things. The problem is _how_ best to maintain and keep up to date the array of comments, though, so that it always contains, in order, a list of the comments that appear as attributes in the text. I thought of just providing -addCommentAtRange: and -removeCommentAtRange: methods and inserting the comment objects to the array (or removing them) directly in these methods at the same time as applying the attribute to the text, but this only goes so far. There is still the problem of what happens when the user copies and pastes some text with a comment in it or deletes a range of text with a comment in it. When this happens, the -replaceCharacters:inRange:... -setAttributes:... etc methods are still going to have to check for a change in
the comments (which is easy enough) and then update the comments array - and it is this latter part which is causing me a headache.
The problem really just lies in keeping things fast. For instance, the following would be a workable solution, but could be too slow:
E.g:
• -replaceCharactersInRange... detects that a comment is being deleted.
• Calls something like -fixUpCommentsInRange:...
• -fixUpCommentsInRange:(NSRange)fixRange uses -attribute:atIndex:range:effectiveRange: to look for comments in either (a) the entire text or (b) from fixRange.location to [text length]-fixRange.location, and adjusts the comments array as necessary.
(It couldn't just look at the current edited range as the comment may now exist in two places, or may have been moved from the end of the text and so the code needs to account for this.)
The above would work, but the trouble is that this would be quite slow for long texts that have lots of comments, where the edit occurs towards the beginning of the text. (Although it wouldn't be an issue for text that has no comments associated with it.)
So the mental block I am having really lies in keeping my array of the KBCommentAttributeName objects (NSDictionary objects in the earlier example) up to date as the user edits the text using the base NSTextStorage methods in a fast and efficient manner, so that -(NSMutableArray *)comments always returns a list of comment objects in the order they appear as attributes in the text. Everything I think of would either be slow or hits another mental block (e.g. if I keep range information inside each comment object so that I could sort the array by range locations, then all comment objects after the current edited range would need updating with their new respective ranges each time the text is edited...).
Many thanks again and all the best,
Keith
> In theory, code is supposed to call beginEdiing/endEditing
> around any operation that edits the text so that might be
> one place you could override to handle this. Other methods
> in NSMutableAttributedString may need to be overridden to
> get information about affected ranges. There are only two
> primitive methods, according to the docs:
>
> - (void)replaceCharactersInRange:(NSRange)aRange
> withString:(NSString *)aString
>
> - (void)setAttributes:(NSDictionary *)attributes
> range:(NSRange)aRange
>
> So those two should provide all the hooks you'd need. If
> your auxiliary array is kept sorted by range position it
> should be easy and efficient to locate the relevant entries
> affected by an edit in a given range. Ideally you'd want to
> manage the comments such that the text storage does all the
> hard work of maintaining the attribute runs/ranges, and all
> you have to do is to add and delete comments in your array
> as necessary.
>
> Still a bit vague, but might help with the inspiration...
>
> --Graham
>
>
>
_______________________________________________
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