In my continuing quest to make sense out of Morphic, I've been  
wrestling with the following problem; I hope that someone can help me  
to a better solution.

I have a Morph, which contains some subMorphs.  For the sake of  
concreteness, the Morph is a view on a die (just a square with  
rounded corners), and the subMorphs are the spots that represent the  
six, or the four, or whatever.  I have code that changes the view  
when the die is thrown; this code works by removing the current set  
of spots and adding the new ones.  The spots are laid out manually,  
not using layout policies or anything fancy; the size and position of  
the spots is computed from the current bounds.

When the outer morph, the DieView, is resized, I obviously need to re- 
do the layout of the spots.  So I wrote something like:

	DieView>>layoutChanged
		super layoutChanged.
		self changeSpotsTo: model value.

which takes advantage of the existing code to set up the spots again.

The problem is that the changeSpotsTo: method does its work by  
deleting the current set of spots and adding a new set.  The removal  
and addition of submorphs causes layoutChanged to be sent to the  
enclosing Morph, the DieView, which causes an infinite call cycle.

The following code works:

	layoutChanged
		super layoutChanged.
		alreadyComputingLayout
			ifTrue: [^ self].
		alreadyComputingLayout := true.
		self changeSpotsTo: model value.
		alreadyComputingLayout := false
	
but I'm ashamed to show this to my class :-(.

What is the "right" way to solve this problem?

Another way of asking this question might be: layoutChanged is used  
to propagate changes in layout UP the Morphic containment hierarchy.   
How should changes be propagated DOWN the hierarchy?

	Andrew


Andrew P. Black
Department of Computer Science
Portland State University
+1 503 725 2411



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070224/8987775d/attachment.htm