Has anyone successful implemented Lion window state restoration that properly restores the scroll position for a custom view that's a scroll view's "document" view?
The behavior that seems to break this is changing the frame of the custom view. AFAICT, it goes like this: I have a window nib that contains a scroll view controlling a custom view. This custom view has an essentially arbitrary size in the nib -- it's resized at window load time to a suitable size. (It's a kind of canvas, so its size depends on the zoom factor and the user-selected canvas dimensions in inches.) If the user has previously zoomed in, increasing the frame size of the custom view, the scroll position appears to have been correctly saved in the scroll view's restorable data, but it doesn't get restored properly at the next window restoration. Here's the sequence of events during restoration: 1. The window is loaded. This means the custom view is loaded at the nib-set size. Let's say that size is 800 x 800. 2. In my case, there's an early KVO notification from the data model that causes the custom view frame to be resized to match the "canvas" size. Since the correct zoom factor isn't known yet, (it's encoded in the view's custom restorable data that hasn't been applied yet), a default zoom factor (100%) is chosen. Let's say this resizes the frame to 1000 x 1000. This step isn't crucial. If I force it to be bypassed, the frame will still be the initial 800 x 800. Ultimately, it makes no real difference. 3. Next, the scroll view applies its restorable data, including the scroll position. This is where things can go wrong. The amount of scrolling is clamped to the current view size: 1000 x 1000 (or 800 x 800 if step 2 was suppressed). If the zoom factor was larger than 100% when the app last quit, the view was bigger than that, so this isn't going to permit enough scrolling. 4. The window mechanism now restores the custom view's custom encoded state, including the zoom factor. The custom view is now resized to the proper size, but the scroll amount is wrong, depending on how much the view was originally scrolled. I can't see any way of getting the custom view frame set back to the correct size *before* the scroll view attempts to restore the scroll position, and I can't see any way of getting the correct scroll position so I can re-apply it later. Does that analysis sound correct? Anyone have a way around the problem? P.S. If the zoom factor happened to be less than 100% the last time the app quit, the amount of restorable scrolling is successfully reapplied on restoration, because the clamping has no effect on a view smaller than 1000 x 1000. Thus, restoring a zoom factor <= 100% works perfectly; restoring a zoom factor > 100% fails if the view was scrolled too far at state save time. P.P.S. I re-watched the 2011 WWDC about window restoration. It worked there in a version of Sketch, but it looks like Sketch handles zooming by changing the clip view bounds to manipulate the NSView display scale transform, not by changing the frame size of the custom view. That means, I guess, that the scrollable view can be set to the proper size initially, assuming that the "canvas" size is a pre-determined page size or something like that. I don't want to scale my custom view like that, because I want to draw object handles and other widgetry at the standard size, not at the zoomed sized like Sketch does. _______________________________________________ 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
