timrowledge
commented
8 years ago This is a problem in the various core fill routines - in a couple of places the code is using 'width -1' and the like, which will cause a lot of trouble when width is 1 and the value is being used as a divisor.
If you d-click in just the wrong sort of place in the painter you can get a divide by 0 error because the area you are trying to fill is 2 or less wide/high.
See Form>>shapeFillGradientFrom:to:at:type: etc.
From the email - Ah, interesting. This isn’t specifically a Scratch bug so far as I can see. what happens is that a graduated fill is done and then if you quickly click again you’re pretty certain to end up trying to gradient fill an area of the previous gradient fill. Since this will almost certainly be an area 1 pixel high (because the gradient makes the next line a different colour) and the code in fillFromYColorBlock: attempts to divid 0 by (1-1), which a a certain Professor Einstein could tell you is a bit tricky. I suspect the original author thought that ‘0 to: (1 - 1) would not evaluate the block at all, or simply didn’t think about single row forms. And checking the ancient original Scratch image shows that back in the last decade that code had a check for the form height being less than 2 - so somebody thought it wasn’t needed at some time after 2005.