On Tuesday 11 September 2001 11:19 am, Tim Rowledge wrote:
> Ned Konz <ned at bike-nomad.com> is widely believed to have written:
> > a _ Morph new
> > 	color: Color white;
> > 	layoutPolicy: TableLayout new;
> > 	listDirection: #leftToRight;
> > 	cellPositioning: #leftCenter;
> > 	hResizing: #spaceFill;
> > 	vResizing: #shrinkWrap.
> > label _ StringMorph contents: 'label: '.
> > textField _ TextMorph new contents: 'text field'.
> > a addMorph: textField; addMorph: label.
> > a openInWorld.
>
> OK, on my image that makes something with the same problem I had before;
> the text field is narrow and does not expand to fill the width of the
> owner morph (and to be still more puzzling, the halo for the owner morph
> suggests it is much narrower than either of the submorphs). Type into
> the text field and you get wrapping immediately and the depth of the
> composite grow, moving the label down to the vertical centre each time.
> I need to avoid these somehow; what I want is a labelled single line
> text entry view, or something very similar. Is there something wrong
> with TextMorph? It's as if it weren't responding to layout messages
> properly. Putting two StringMorphs together doesn't cause the problem
> (but doesn't make for an editable filepath either!).

No, it's just got a lot of options. Try this, which works for me, though 
it'll still wrap over-long lines (by changing autoFit, as I recall, you can 
make it not resize vertically when it wraps):

a _ Morph new
        color: Color white;
	extent: 300 at 20;
        layoutPolicy: TableLayout new;
        listDirection: #leftToRight;
        cellPositioning: #leftCenter;
        hResizing: #spaceFill;
        vResizing: #shrinkWrap.
label _ StringMorph contents: 'label: '.
textField _ TextMorph new
	contentsAsIs: 'text field';
	leftFlush;
	wrapFlag: true;
	hResizing: #spaceFill.
a addMorph: textField; addMorph: label.
a openInWorld.

> > Why the fondness for AlignmentMorphs? They're more or less obsolete, you
> > know, since all the layout stuff got moved to Morph.
>
> I discovered that last night after reading the 'controlling your
> submorphs' article in the new copy of SqueakNews, but since an
> AlignmentMorph is a (suppossdly) innocuous holder like a rectangle
> morph, I don't imagine it causes any harm. Or does it?

I don't know; it turns on rubberBandCells, for instance, which I usually 
don't want for things like this. I just feel that it's better to be explicit 
about settings.

> If you turn scrollbars back to flop-out, you'll see the very odd effect
> of going from one ofthe lists to the other. It doesn't happen with fixed
> scrollbars.

> Trouble is that that prevents making nice composites and plugging them
> in, which seems a pity. Surely this nesting stuff ought to work better?

It does, as long as you don't combine flop-out scrollbars with horizontal 
layout logic. The problem is that the Morph width changes when the scrollbar 
flops out, which causes its parent to have to lay itself out again.

What else did you expect to happen when the Morph width changed? Ignoring for 
a minute the way that you _want_ the scrollbars to work, this is no different 
than a child RectangleMorph suddenly deciding that it wants to be an extra 30 
pixels wide.

My recommendation is to somehow pin the scrollbars down as internal ones (is 
this possible on a per-Morph basis?), or stick ScrollPanes inside rigid 
containers, not ones that are trying to do horizontal table layout. You may 
have to add layout logic to make this work the way you want.

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com