Thanks for the info > BTW you decided to fight against framework (as others mentioned state > restoration is responsible for this).
The documentation on state restoration is somewhat sparse. However, as I understood, it only kicks in when I re-open an application. When the user opens a document after opening the application, state restoration would not restore that document — would it? > On 21 Sep 2015, at 23:52, Marek Hrušovský <xhrus...@gmail.com> wrote: > > Personally I would do it like this: > 1. Figure out what values you need to store > 2. Create custom object called configuration; for each window one kind > 3. Make it conform nscoding and add a delegate property (which will point to > windowcontroller) > 3. implement initwithcoder/encodewithcoder > 3. add this to your model > > Saving: > As usual > > Loading > 1. override setDocument on your windowController > 2. call super > 3. get the configuration from document, set it's delegate and apply it where > you need it > > I thought of other approaches but they were more ugly or involved more code. > BTW you decided to fight against framework (as others mentioned state > restoration is responsible for this). > Also don't forget to call updateChangeCount (if you don't support undo). > > > > On Mon, Sep 21, 2015 at 9:46 PM, Kurt Sutter <k...@quansoft.com > <mailto:k...@quansoft.com>> wrote: > Thanks, Marek > > So how would I go at this? Since I want to store that data into the document, > I’d need, in dataOfType:error:, to create a NSKeyedArchiver, and then would I > just encode self.windowControllers? Then, in readFromData:ofType:error:, I > would read in the coder, and in makeWindowControllers I would then re-create > the window controllers? Would that work? (I have started to try exactly that, > but I have not yet succeeded with making it work. It somehow seems a bold > thing to do.) > > Kurt > > >> On 21 Sep 2015, at 20:22, Marek Hrušovský <xhrus...@gmail.com >> <mailto:xhrus...@gmail.com>> wrote: >> >> I am far from architect but each window has an option "initWithCoder" and >> within XIB you can specify option "prefer coder instantiation". The >> information you want to store is not related to the model object (within >> document) cannot be reused. >> So basically I would implement NSCoder methods encode/init withCoder >> >> Marek. >> >> On Mon, Sep 21, 2015 at 8:09 PM, Kurt Sutter <k...@quansoft.com >> <mailto:k...@quansoft.com>> wrote: >> Hi all >> >> I am trying to figure out how to store information about my windows and >> views in a document, and how to restore it. Note that I am talking about >> storing the information in the document itself, not in the application’s >> preferences settings. >> >> Specifically, I have a child of NSDocument that saves its model data using >> dataOfType:error: and restores it using readFromData:ofType:error: That >> works fine. Now, that document may have a variable number of windows for >> showing aspects of the data of the document’s model, and each window has a >> number of views. The windows and views contain state information, such as >> scroll positions, window positions, zoom factors, etc. >> >> I want the state information of the windows and views to be stored in the >> document so that the same windows and views reopen when the user opens the >> document. >> >> What is the best way to do that? I guess I have to take two steps: >> >> (a) collect that state information in dataOfType:error: and store it in the >> NSData object to be returned and >> (b) retrieve that data from the NSDocument in readFromData:ofType:error: and >> then somehow apply it in the NSDocument’s makeWindowControllers method. >> >> While both of this is certainly feasible, I am not sure what is the most >> elegant way to do it. Do I run encodeWithCoder against the document’s window >> controllers during save, and then somehow restore the window controllers in >> the makeWindowControllers? Or what else? >> >> I have tried to find pointers on how to do this in the most elegant manner, >> but I found nothing useful. So I would greatly appreciate any proposals. >> >> Thanks in advance >> >> Kurt >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com >> <mailto:Cocoa-dev@lists.apple.com>) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> <http://lists.apple.com/> >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/xhruso00%40gmail.com >> <https://lists.apple.com/mailman/options/cocoa-dev/xhruso00%40gmail.com> >> >> This email sent to xhrus...@gmail.com <mailto:xhrus...@gmail.com> > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
