On Jan 19, 2009, at 14:54, Graham Cox wrote:
Well, it's not really in an unsaveable state. The data model itself
isn't damaged by exceptions thrown from the drawing code. However,
the visual appearance of the document is badly upset (scrollbars
suddenly disappear, rulers get drawn in the middle of the view,
etc). The user *thinks* something has gone terribly wrong, panics,
and typically closes the document without saving. In fact saving at
that point will work OK, but we're finding that users typically
think it's become "corrupt" and are loth to save over an earlier
version of the document because they think that what they see is
what they will get - i.e. saving the document with a corrupted view
will make the problem permanent. The end result is the same though -
the user has "lost" their data, even though in fact they didn't need
to. This is why I need to ensure that a minor glitch when drawing
doesn't get blown out of all proportion.
So Plan A would be to try to recover the drawing state, turn off your
drawing (because presumably the same exception would occur if the
window redrew), get safely back to the main event loop, and put up a
Save As dialog with a message that the application needs to quit
because of an internal error and asking for a place to save a copy of
the document? As a user, I'd be sold on that idea, I think.
IMO, the issue is (at least initially) a matter of documentation.
The NSGraphicsContext class reference is ambiguous and incomplete
-- it's not clear whether the current context is saved *in* each
state on the state stack, or whether the state stack is *in* the
current context, or whether the state *is* the context. There's
apparently a setGraphicsState: method which *looks* like it might
be what Graham needs to set things back to a known state, but the
parameter to this method isn't documented anywhere I could find.
The header file is no help at all. The comments refer to save/
restore *context* methods (as opposed to save/restore *state*
methods) which apparently don't exist anywhere.
If the documentation was clear, I think Graham's strategy for
dealing with exceptions would also become clear.
Yep, I guess this is getting at the heart of my problem (Thanks for
putting it so much more succinctly than I have managed so far!). I
guess I'm hoping someone familiar with NSGraphicsContext can help me
understand if saving and restoring a context explictly is legal
(what happens to all the saved states that were stacked up in the
process?) or if not, what is an appropriate alternative. In practice
it seems to work, but I need to know that I'm not storing up trouble
for myself.
The question is whether you're really saving and restore a context, or
just states. According to my reading of the documentation, you're not
actually going to switch NSGraphicsContext unless you need to do (say)
buffered drawing into a NSBitmapImageRep-based context. There's no
stack of contexts to reset unless (a) the state save/restore includes
the current context or (b) states and contexts are really the same
thing.
My reading of (most parts of) the documentation suggest that the state
consists of the drawing parameters of the context, but not the context
itself.
So it's unclear why recovering by setting the context (as you tried)
has any effect at all (unless you had changed contexts yourself).
Now would be a good time for someone who really knows something to
jump in and enlighten us. :)
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
