As we know, the Versions Browser causes your app to open an actual document for each version it displays in the Browser.
If you have large documents that cause a complex drawing to need to be rendered, the experience is horrible - each version takes seconds to open and more seconds to display. The system can beachball for a long, long time as the VB is entered, maybe many minutes if there is a long edit history. I'm trying to avoid some of these delays by caching a snapshot image of my window contents when I save the file, and use this snapshot when browsing in the VB instead of opening the real file contents and rendering it (VB should be doing this automagically itself in my opinion). When my document enters the VB, I get notified that it has done so via the NSWindowDelegate method -windowDidEnterVersionsBrowser: and when exiting I get the exit notification. This tells me when the *window* has entered the VB, but when the -[NSDocument readFileWrapper:...] method is called, as it is many times as each old version is opened in the VB, there is no window yet, so there's nothing to tell me that this document is being opened by the VB rather than normally. Even when its window is finally created and opened, the 'entered VB' notification isn't sent. I need a way to know at -readFileWrapper: time if I'm in the VB or not (so I can load the snapshot image instead of the heavy file content). I've so far done this by setting a global flag when I get the 'entered vb' message and unflagging when I get the 'exited VB' message, but this feels hacky and potentially unreliable. Is there a sound way to determine at document creation time whether the VB is active or not? Ideally this would be for the actual document in question rather than globally, because while it doesn't seem to be possible in the current implementation, the architecture appears to permit documents to be opened "normally" even while the VB is active for a different document. How do others hande this? Do you just accept that the VB is a total dog unless your files are trivial, or are there good workarounds to get acceptable performance? --Graham _______________________________________________ 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
