<div dir="ltr"><div>Here is the code:<br><br>setExtent: extent depth: bitsPerPixel bits: bitmap<br>    &quot;Create a virtual bit map with the given extent and bitsPerPixel.&quot;<br><br>    width := extent x asInteger.<br>
    width &lt; 0 ifTrue: [width := 0].<br>    height := extent y asInteger.<br>    height &lt; 0 ifTrue: [height := 0].<br>    depth := bitsPerPixel.<br>    (bits isNil or:[self bitsSize = bitmap size]) ifFalse:[^self error:&#39;Bad dimensions&#39;].<br>
    bits := bitmap<br><br></div><div>If we look at the guard for bitsSize, there are two things weird:<br><br></div><div>- the test bits isNil disengage the guard the first time this initialization is sent, that is virtually every time (did we ever tried to recycle a Form this way?)<br>
</div><div>- the test could be bitmap isNil or: [...<br></div><div>but in this case we can no longer initialize a Form read from png for example (see examples in PaintBoxMorph class &#39;resources&#39;), because such initialization occurs with a ByteArray...<br>
<br></div><div>So the test could be<br>    (bitmap isNil<br>        or: [(bitmap class isWords and: [self bitsSize = bitmap size])<br>        or: [bitmap class isBytes and: [self bitsSize * 4 = bitmap size]]])<br></div><div>
(or the same with <br></div><div>but then this would forbid initialization with compressed (hibernated) ByteArray format (no idea if it is used...)<br><br></div><div>The alternative is to completely remove the guard  I don&#39;t know if the BitBlt primitives are protected enough from bitmap overflow, but anyway as demonstrated above the guard is not active.<br>
<br></div><div>It&#39;s always questionable to touch those parts sealed by famous predecessors (di, ar, ...).<br></div><div>It ain&#39;t really broken, and even Juan did not change it in Cuis.<br></div><div>But I feel like those Form have accumulated some dust and could shine a bit brighter.<br>
</div><div><br></div></div>