Re: Serialization of BorderedMorph

Hi Stef --

Would a safeguard "Project current addDeferredUIMessage: [ ... ]" or "[ 
... ] on: Error do: [:ex | ]" help for your case?

Best,
Marcel

Am 15.08.2026 um 17:35 schrieb Stéphane Rollandin:
> Hello all,
>
> Still examining the various side effects of loading my old code in a 
> 6.1 image...
>
> I found something rather disturbing:
>
> When a BorderedMorph is reading from a file (or from any ref stream), 
> its own (and very recent) implementation of #readDataFrom:size: sends 
> #borderColor: and #borderWidth: (that is intended for backward 
> compatibility).
>
> This may have tricky side effects though, because both #borderColor: 
> and #borderWidth: trigger #changed, which may itself update the layout 
> of the morph. Since this happens while the morph is being read, in a 
> context where the overall structure it is part of is not in a 
> consistent state.
>
> More generally, we do not know beforehand what a specific 
> implementation of #borderWidth: may do.
>
> For example, in Connectors, one implementation iterates over 
> submorphs. This breaks if the submorphs inst. var. is nil at that 
> point, which is the bug I got. It made it impossible to load the muO 
> documentation, which is made of very complex morphs.
>
> So in my use case, the fix to provide backward compatibility actually 
> broke it :)
>
> I can work around this on my side, but I believe this is a quite 
> dangerous pattern: a Morph should not be tweaked in potentially 
> arbitrary ways while it is being instanciated from a ref stream.
>
>
> Stef
>
>
>
> Squeak-dev mailing list -- [email protected]
> To unsubscribe send an email to 
> [email protected]
Squeak-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]