Odd behavior of SystemWindowWithButton and TableLayout

Jesse Welton jwelton at pacific.mps.ohio-state.edu
Fri Jul 20 13:24:01 UTC 2001


Ross Boylan wrote:
> 
> I have a subclass of SystemWindowWithButton that I set up like this:
> initialize
> 	super initialize.
> 	self color: Color paleYellow;
> 		hResizing: #shrinkWrap;
> 		vResizing: #shrinkWrap;
> 		listDirection: #topToBottom;
> 		wrapDirection: #leftToRight;
> 		layoutPolicy: TableLayout new.
> 
> I then populate it with calls to addMorph:
> 
> When it's done, the "title bar" appears simply as one of the list
> items (the last).   Is there a way to get it to stay as the title to
> the whole window and yet get the layout?  (I assume I could get there
> by embedding another window in the SystemWindow; I'm looking for
> something a little simpler).

I don't think you'll be able to get the results you're looking for
without using an intermediate submorph.  You don't have to embed
another window, just a simple Morph that will serve as your table
region.  It's not difficult at all, and in fact is used in many places
for the standard tools.

I'm not sure how you could get the window to use #shrinkWrap resizing,
though.  You might have to do that explicitly in your subclass.

> If I addMorphBack: then the title bar appears first and my items are
> in "natural" order.

The title bar may be first, but it's surely not in the right position.
You have a big black bar across the top of your window, yes?  That's
because the SystemWindow's layoutBounds start below the intended title
bar area.  The title bar isn't usually affected because
ProportionalLayouts don't touch any submorphs without a LayoutFrame,
like the title bar.  (SystemWindows resize their title bars
explicitly.)  TableLayouts, on the other hand, affect all submorphs.

Adding a pane which will hold your table of Morphs will be FAR simpler
than trying to work around such deeply ingrained assumptions of
SystemWindows.  Getting it to resize to fit the table will be a little
trickier, but you should be able to do it explicitly without too much
difficulty.

> As an aside, is the current behavior in which listDirection:
> #topToBottom + addMorph adds each element to the top of the list
> really a feature?  It seems more like a bug to me.

It's a little tricky, but it does make sense.  #addMorph: is
equivalent to #addMorphFront:, which most often really is what you
want.  Then, listDirection: #topToBottom arranges the morphs in order
(first=front, last=back) from top to bottom.  An alternative to using
addMorphBack: would be to use reverseTableCells: true.

-Jesse





More information about the Squeak-dev mailing list