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 mi
On 20 Jan 2009, at 5:24 am, I. Savant wrote:
On Jan 19, 2009, at 12:57 PM, Paul Bruneau wrote:
I'm confused by it, since I have been directed in the past by
people who know that The Cocoa Way is to have objects know how to
draw themselves--via a category if desired.
Is there differing op
On Jan 19, 2009, at 2:08 PM, Quincey Morris wrote:
I don't get this at all (not just the quoted comments, but going all
the way back to Graham's original statement).
-- If a failure in the drawing code destroys the *data model*
(thereby preventing it from being saved) then there's something
On Jan 19, 2009, at 10:16, Shawn Erickson wrote:
On Mon, Jan 19, 2009 at 9:57 AM, Paul Bruneau
wrote:
On Jan 19, 2009, at 2:49 AM, Kyle Sluder wrote:
3) You've over-architected your drawing code. Typically the fewer
objects that are responsible for drawing (i.e. view objects) the
better. S
On Jan 19, 2009, at 12:57 PM, Paul Bruneau wrote:
I'm confused by it, since I have been directed in the past by people
who know that The Cocoa Way is to have objects know how to draw
themselves--via a category if desired.
Is there differing opinion on this? (apparently there is...)
This
On Mon, Jan 19, 2009 at 9:57 AM, Paul Bruneau
wrote:
> On Jan 19, 2009, at 2:49 AM, Kyle Sluder wrote:
>
>> 3) You've over-architected your drawing code. Typically the fewer
>> objects that are responsible for drawing (i.e. view objects) the
>> better. Situations like the one you're describing o
On Jan 19, 2009, at 2:49 AM, Kyle Sluder wrote:
3) You've over-architected your drawing code. Typically the fewer
objects that are responsible for drawing (i.e. view objects) the
better. Situations like the one you're describing often arise from
making model objects responsible for their own d
On Mon, Jan 19, 2009 at 6:07 AM, Graham Cox wrote:
> What does appear to help a lot is saving the current context at the top of
> the drawing stack and putting it back explicitly at the end (as per my
> previously posted code snippet). If the save/restores are balanced,
> effectively this is a no-
On 19 Jan 2009, at 6:49 pm, Kyle Sluder wrote:
Well it sounds like there are a number of issues here:
1) You're throwing exceptions in drawing code. Even if you catch them
so they don't screw up the draw stack, this will be extremely slow and
have adverse effects on the drawing.
My understa
On Mon, Jan 19, 2009 at 2:32 AM, Graham Cox wrote:
> Naturally I would prefer that no exceptions can ever be thrown in this code.
> But the reality of development is, that yes, sometimes they do. Very often
> this is from an NSAssert message which are liberally used throughout most of
> the code.
On 16 Jan 2009, at 8:33 pm, kyle.slu...@gmail.com wrote:
What are you doing that could throw an exception? After all,
exceptions are used to indicate programmer error, and are expensive to
throw. Something tells me that you shouldn't be worrying about
exceptions in your drawing code to begin
On 16 Jan 2009, at 10:33, kyle.slu...@gmail.com wrote:
What are you doing that could throw an exception? After all,
exceptions are used to indicate programmer error, and are expensive to
throw. Something tells me that you shouldn't be worrying about
exceptions in your drawing code to begin wi
What are you doing that could throw an exception? After all,
exceptions are used to indicate programmer error, and are expensive to
throw. Something tells me that you shouldn't be worrying about
exceptions in your drawing code to begin with.
--Kyle Sluder
On 15 Jan 2009, at 3:53 pm, Kyle Sluder wrote:
This is known as a "continuation". Scheme, for example, often uses
them instead of exceptions. Much like a jmp_buf, It contains all of
the information necessary to resume execution at the point the
continuation is created. In the event of an err
On Wed, Jan 14, 2009 at 11:34 PM, Graham Cox wrote:
> If an exception is thrown from somewhere down inside this stack, I'd prefer
> it if I could continue to draw what can be drawn, rather than have to abort
> the drawing altogether which usually leaves the whole view in a weird state
> (at which
Suppose I have a drawing stack that is called from a view's drawRect:
method. This stack can end up quite deep, with objects calling other
objects to implement parts of their drawing. Some of these methods
will save and restore the graphics context.
If an exception is thrown from somewhere
16 matches
Mail list logo
