Lion autosave loses NSTextView position/selection
Lion autosave loses NSTextView position/selection
- Subject: Lion autosave loses NSTextView position/selection
- From: Fritz Anderson <email@hidden>
- Date: Fri, 11 Nov 2011 11:00:35 -0600
10.7 SDK, targeting 10.6 and 10.7.
My application writes an XML document that includes styled text in the form of HTML. At the user end is an NSTextView; I use an in-memory Core Data store for working storage. The text view is bound to the backing NSManagedObject through an NSArrayController. I have an NSValueTransformer subclass between the text view and the array controller to translate between the attributed string and NSData containing the HTML.
So the chain is:
NSTextView
^
|
(NSAttributedString)
|
v
NSValueTransformer
^
|
(NSData - HTML)
|
v
NSArrayController
^
|
v
NSManagedObject data attribute
And my NSDocument subclass uses a utility class of mine to walk the managed-object context to create the XML file, with the rich-text HTML as CDATA. It has to be HTML, because it's for display on an iPad.
Maybe I'm too lazy, but my document implements only -dataOfType:error: and -readFromData:ofType:error:. The first thing -dataOfType:error: does is to send commitEditing to the NSControllers.
My document returns YES from -autosavesInPlace, and implements -encodeRestorableStateWithCoder: and -restoreStateWithCoder:.
MY PROBLEM
Under Lion (I haven't checked with Snow Leopard), when an autosave is triggered, the active NSTextView loses its selection and scrolls to the top.
This happens in -dataOfType:error:, before my encode/restoreState methods (in which I've tried saving selection ranges and first responder) are called. By the time encodeRestorableStateWithCoder: is called, self.textView.selectedRange points to the end of the string, regardless of where the selection had been.
When I single-step through dataOfType:error:, I see that the scroll bar on the active text view appears (matching the current position) when I call commitEditing on the view's controlling NSArrayController.
Snatching the user's work from under his hands is a horrible experience. How can I fix this?
— F
_______________________________________________
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