On 23.05.2011, at 05:04, David T. Lewis wrote:

> On Sun, May 22, 2011 at 04:37:24PM -0400, David T. Lewis wrote:
>> On Fri, May 20, 2011 at 10:17:29PM -0700, Jerome Peace wrote:
>>> 
>>> http://bugs.squeak.org/view.php?id=7635
>>> Summary 	0007635: Graphics primitives will raise errors when rectangles have widths in fractions.
>>> Description 	For this one in a work space evaluate
>>> 
>>> box :=
>>> RectangleMorph new openCenteredInWorld .
>>> 
>>> box bounds: ((375 at 280 corner: 425 at 320) insetBy: (3/4)).
>>> 
>>> The alternate form:
>>> box bounds: ((375 at 280 corner: 425 at 320) insetBy: (0.75))
>>> 
>>> will work without error.
>> 
>> Thanks, this is fixed in trunk now.
>> 
> 
> In Mantis 7635 (Graphics primitives will raise errors when rectangles have
> widths in fractions), Jerome points out quite rightly that the "self error:"
> in BitBlt>>copyBits is a bad thing (indeed it crashes the image when updating
> a morph with bounds containing a fraction), and suggests that the problem be
> fixed in #copyBits. Removing the error notification in #copyBits resolves
> the problem, because this is fallback code for the failed primitive which
> does the right thing by fixing the parameters and calling the primitive a
> second time. However, removing the error notifier also masks a real problem
> that would otherwise have gone undetected (which I presume is the reason
> the notifier was put there in the first place).
> 
> Summary: The potential for crashing the image in this case is a long-standing
> problem. We could make it go away to removing the problematic error notifier
> (which crashes the image when invoked from the morphic update loop). However,
> this fix would allow problems such as that reported in Mantis 7635 to go
> undetected.
> 
> Opinions?
> 
> Background at <http://bugs.squeak.org/view.php?id=7635>
> 
> I am somewhat inclined to think that it is better to leave the error
> notifier in place, even though it can and will crash the image in
> some circumstances. But better yet would be if someone can think
> of a way of detecting the problem in some way that does not involve
> potentially crashing the image.
> 
> Dave

This should have worked fine. Errors during the Morphic draw loop normally are caught. I'd not take out the error notification, but rather bullet-proof drawErrorOn:. 

In fact, I just committed Morphic-bf.543 to do that. For testing you can revert Morph>>extent: and try the fraction example again. You now simply get a debugger rather than a fatal error, just like the Morphic Gods intended ;)

There is a problem that some classes overriding fullDrawOn: do not check for the errorOnDraw property. E.g. I just had to add the check to HandMorph's override, otherwise I'd get the same fatal error when picking up the broken morph. I did not fix the other implementors.

- Bert -