The attached changeset should fix the problem Andreas mentions.  Hopefully it also fixes Tim's problem, I'm not sure. (see below)

Andreas Raab wrote:
> 
> I've seen the problem in a different context. It's been coming in with
> CS 4722fixScrollbarOnRight-sm and it says:
> 
> ScrollPane>>showScrollBar
>         (submorphs includes: scrollBar)
>                 ifTrue: [^ self].
>         self resizeScrollBar.
>         self privateAddMorph: scrollBar atIndex: 1.
>         retractableScrollBar
>                 ifTrue:
>                         ["Bring the pane to the front so that it is
> fully visible"
>                         self comeToFront.
>                         self owner ifNotNil: [self owner comeToFront]]
>                 ifFalse: [self resetExtent]

The attached changeset changes this second-to-last line to:

			(self owner notNil and: [self owner isAlignmentMorph])
				ifTrue: [self owner comeToFront]]

Perhaps a bit ugly, but not horrible. :-\

> Watch the line "self owner comeToFront" - this leads to a) having system
> windows randomly jump to the top of the world if you mouse over a list
> (like in the browser) and b) will naturally make your list jump to the
> front of the aligmnent (and thus switch order).
> 
> I don't know what exactly the idea was - the aforementioned CS has this
> change as its only contents and so I _guess_ there was some reason for
> it (considering that the previous version did the same - but only for
> scrollbars on the right which is _still_ broken ;-) I just can't figure
> which one....

Hmm, flop-out scrollbars on the right works for me, at least in 3.2gamma.  But anyway, I guess Simon's original changeset had the "self owner comeToFront" because the class list (2nd from left) pane in a Browser is embedded in an AlignmentMorph, which caused the flopout-scrollbar-on-right to be partly obscured... so the AlignmentMorph needs to comeToFront too.  But most of the time the owner is the SystemWindow, which we don't want coming to the front...

(Ooh, I bet Tim's problem is not fixed, because the vertical ordering is based on which morph is frontmost, or something?)

- Doug Way
  dway at riskmetrics.com


> Cheers,
>   - Andreas
> 
> > -----Original Message-----
> > From: squeak-dev-admin at lists.squeakfoundation.org
> > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On
> > Behalf Of Tim Rowledge
> > Sent: Thursday, February 14, 2002 11:51 PM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: [BUG] 3.2g-4743 problem with lists in morphic
> >
> >
> > I've just spotted a new and mildly amusing bug in the 4743
> > update image.
> > It seems something odd is happening wrt alignment of morphs, in
> > particular the stuff involved in VMMakerTool>buildWindow.
> >
> > The symptom is that the window opens looking as per normal, with the
> > three lists at the bottom. As you can see from the code in
> > #buildWindow
> > I am using an AlignmentMorph newColumn with a TextMorph for a
> > label and
> > a PluggableListMorph. If you enter the area of the AlignmentMorph, the
> > vertical ordering of those two submorphs is swapped. They do not swap
> > back when you leave.
> >
> > This worked just fine in #4653.
> >
> > tim
> > PS VMMakerTool is included in
> > http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas/VMMaker-
> 3-2-version5.3.cs
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> EBCDIC: Erase, Back up, Chew Disk, Ignite Card
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SysWindowsPoppingUp-dew.cs.gz
Type: application/octet-stream
Size: 517 bytes
Desc: Unknown Document
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20020215/8751a995/SysWindowsPoppingUp-dew.cs.obj