[squeak-dev] BorderedMorph initialisation, trackColorFrom: bug

tim Rowledge tim at rowledge.org
Fri Oct 14 19:50:58 UTC 2016

I’ve just been working out why the assorted Scratch dialogboxes seem to have lost the inset borders on all their string input submorphs. Since the #inset borderColor doesn’t actually create the border style stuff until rather later in the process, and trapping it in the wrong place whacks one with the emergency evaluator, this was fun. Like chewing on chocolate coated razor blades kind of fun.

Anyway, so far as I can see there are two recent changes related to this in SimpleBorder
a) #trackColorFrom: was altered to simplify it and now does nothing if ‘baseColor’ is non-nil.
b) the #initialize method was altered to make baseColor default to transparent.

Thus unless you explicitly set the base color in some fashion the prior behaviour of the border tracking the color of some morph in its owner chain is blocked. It also breaks the simple last example usage in the class comment since the resulting morph has not visible border.

My solution is to just leave the baseColor out of the initialize method. That appears to make Scratch happy, doesn’t seem to cause any problem with any other usage I can spot and seems the right thing to do. Absent objections with accompanying good reasons I’ll push it out later on.

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: JUM: Jeer at User's Mistake

More information about the Squeak-dev mailing list