NSTextStorage subclass
NSTextStorage subclass
- Subject: NSTextStorage subclass
- From: Rachel Blackman <email@hidden>
- Date: Fri, 27 Jan 2006 01:05:54 -0800
So, in another textview project unrelated to my last few textview questions (promise!), I've subclassed out NSTextStorage. For purposes of this message, the nature of the subclass doesn't entirely matter; I've tested the individual methods, and they seem to work. I will detail it below for informational purposes, however.
However, when I call [self edited:...] to notify of updates as all the 'subclassing NSTextStorage' stuff recommends, I get a SIGBUS. Now, self is (obviously) valid, and Google searching doesn't seem to find anything. I'm at a bit of a loss... anyone else subclassed NSTextStorage and run across a problem like this?
The subclass, for those who care, is actually backed by an NSMutableArray containing multiple NSAttributedString objects. The NSTextView is read-only (the replace and delete functionality is empty), and appendAttributedString is altered to add the new string onto the end of the array. The attribute checking methods are overridden to find which string that position is in, and get the appropriate attributes. The 'string' method itself is overridden to return a cached string copy of the entire array (the cache is cleared every so often, or when the array is altered).
The reasons for this are not particularly relevant to my question, but in short I have something akin to a log file (but with rich, attributed strings) which may have a very great many lines. Many of these lines are duplicated exactly across multiple textviews, and all of which must be stored in a single master array for later reference. No view will ever have replace/delete characters done on it.
Given this, having a single copy of each of the attributed strings shared among all the appropriate views and the master list of everything seemed more memory-efficient to me. But, unfortunately... *points above*
Any advice?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden