Date
1 - 6 of 6
Arg! Document window restoration. Again.
|
Steve Mills
On Aug 1, 2019, at 09:30:12, Quincey Morris <quinceymorris@...> wrote:
I got it to work by calling the window's restoreStateWithCoder: instead of the document's. Another complication with #4 is that you’re on the hook to deal with changes in monitor configuration. If the screen sizes changes, or screens are added or removed, before the document is re-opened, you have to reposition the document sensibly. Built-in mechanisms for positioning the window do this for you in cases #1-#3.In my tests, it takes care of this and repositions the window so it's on the currently available screen[s] if the previous screen is not available. Yet another complication is the problem of what to do about read-only documents (or editable documents that aren’t dirty). Saving the window frame means you have to change the document file, so you’ll need to save and restore the file’s modification date around the change (if you can), or discard the frame (if you can’t).Not a problem. If the doc file's locked, I ain't changin' nothing'! -- Steve Mills Drummer, Mac geek |
|
|
|
Quincey Morris
On Aug 1, 2019, at 06:00 , Steve Mills via Groups.Io <sjmills@...> wrote:
No, the window autosave name predates state restoration by a lot of years. IIRC, the behavior breaks down like this: 1. Window restoration (if enabled) overrides everything else, for windows that are being re-opened at launch. 2. Otherwise, the autosave frame is honored when a window of that type (a window having that autosave name) is opened. 3. Depending on the rest of the window configuration, multiple windows of the same type may be cascaded when opened. 4. Document windows are generally all of the same type, so there is no standard per-document behavior. If you want documents to return to their original frame when opened, you must store the frame in the document and set the window frame manually. #4 is a bit tricky when you’re using state restoration, because documents are opened via your regular code path before the restoration frame is applied. You have to be careful to avoid dueling frames producing strange results. Another complication with #4 is that you’re on the hook to deal with changes in monitor configuration. If the screen sizes changes, or screens are added or removed, before the document is re-opened, you have to reposition the document sensibly. Built-in mechanisms for positioning the window do this for you in cases #1-#3. Yet another complication is the problem of what to do about read-only documents (or editable documents that aren’t dirty). Saving the window frame means you have to change the document file, so you’ll need to save and restore the file’s modification date around the change (if you can), or discard the frame (if you can’t). |
|
|
|
Keary Suska
Did something change recently? frameautosave has historically been the way to save a window’s frame, regardless of when the window was opened. Maybe you should take a second look. If you have a simple controller-window setup, you could also look at windowFrameAutosaveName.
toggle quoted message
Show quoted text
Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" On Aug 1, 2019, at 7:00 AM, Steve Mills via Groups.Io <sjmills@...> wrote: |
|
|
|
Steve Mills
On Jul 31, 2019, at 23:57:33, Jon Gotow <gotow@...> wrote:
From what I've experienced and read, that only helps for reopening docs on app launch, not on opening docs once launched. The OS only stores info for docs that were open when the app exits so it can restore the app to the same state (as long as you have "Close windows when quitting an app" turned off in System Prefs). -- Steve Mills Drummer, Mac geek |
|
|
|
Jon Gotow
Can't you just set NSWindow.frameAutosaveName? Or does NSDocument get in the way of that?
toggle quoted message
Show quoted text
- Jon On Jul 31, 2019, at 10:09 PM, Steve Mills via Groups.Io <sjmills@...> wrote: |
|
|
|
Steve Mills
Doc and window restoration is great when relaunching the app, but I also want each document's window to open to their last frame when the user opens documents. I can not find the right place to make that happen. I supposed I'll need to subclass the window controller or window? What I thought would work was to grab the saved restoration data (which I saved in the document by calling -encodeRestorableStateWithCoder: and specifically adding the window frame with a custom key in -window:willEncodeRestorableState:), feed the data to an NSKeyedUnarchiver, and pass that to -restoreStateWithCoder: from my document subclass' -windowControllerDidLoadNib: method. But that appears to do nothing. It doesn't even get around to calling the document's -window:didDecodeRestorableState: override.
Every time I need to do something beyond the basics with window restoration, I dread it because I know it will suck. -- Steve Mills Drummer, Mac geek |
|
|