I am explicitly calling encodeRestorableState (in windowWillClose) and restoreStateWithCoder (in windowDidLoad), storing and reading the data to/from a file myself. I know those are normally used as part of the automatic app state restoration, but I want to restore a window's state regardless of whether it was open when the application last quit.
I'm using encode/restoreState because it's an existing mechanism that seems to suit my needs, and aside from this first responder thing it's working fine. Also, I'm assuming - though I haven't tested this yet and the docs don't say - that the window state restoration will take into account changes in the monitor configuration, ensuring that the window is restored to a location that is still on screen. If there's a better way to do that I'm open to it. On Thu, Feb 16, 2017 at 11:52 AM, Quincey Morris < quinceymor...@rivergatesoftware.com> wrote: > On Feb 16, 2017, at 10:09 , David Catmull <davidcatm...@gmail.com> wrote: > > > I'm working on using encodeRestorableState/restoreStateWithCoder to save > and restore the state of a window. (I'm doing this manually because I want > to explicitly save my window state in the document and not just rely on the > OS restoring its state as part of restoring the application state.) > > > It’s a while since I’ve had to wrestle with custom restoration, so maybe > I’m missing something obvious, but I can’t quite come to grips with what > you’ve said here. > > On the face of it, if you’re saving the window state in the document, you > should not be using window restoration *at all*. Instead, you should simply > configure the window back to how/where it should appear as part of the > document opening process, after creating the window controller and before > showing the window — in an override of NSDocument’s “makeWindowControllers” > probably. > > If by "encodeRestorableState/restoreStateWithCoder” you mean the standard > NSResponder methods, then the saved state is *not* saved in your document, > and restoration likely happens — or at least starts — before your > NSDocument instance exists. You then fall into a timing and state > consistency hole (the window being restored is created early in app > startup, the document information is available later), so I don’t find it > entirely surprising that an error occurs. > > If I’m off track here, can you clarify what you’re trying to do with the > actual state restoration mechanism, if it’s not to save/restore its own > state data? > > _______________________________________________ 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
