On Fri, 2003-12-19 at 08:31, Ken Causey wrote:

Just a followup to say this issue is still true in 3.7a-5607. Anyone care to point out if instead of a bug I'm making a mistake here?

Ken

On Tue, 2003-02-25 at 14:26, Ken Causey wrote:

...

( PluggableTextMorph on: nil text: nil accept: nil readSelection: nil menu: nil ) extent: 50@100; editString: 'This is some really long text that will hopefully cause the PTM to wrap and a scollbar appear'; hResizing: #shrinkWrap; openInWorld.

Now either extend the text or just wiggle the scrollbar and watch the PluggableTextMorph widen and widen. The hResizing: #shrinkWrap seems to lead to this behaviour.

Ken

The following code has the same problem: (PluggableListMorph on: #(A b c d e f g h i j k l) list: #contents selected: nil changeSelected: nil) color: Color green; hResizing: #shrinkWrap; fullBounds. openInWorld

replace the normal wondow building method in ObjectExplorer with the following: explorerFor: anObject | listMorph | rootObject _ anObject.

(listMorph _ SimpleHierarchicalListMorph on: self list: #getList selected: #getCurrentSelection changeSelected: #noteNewSelection: menu: #genericMenu: keystroke: nil).

listMorph autoDeselect: false; hResizing: #shrinkWrap. ^listMorph

or introduce hResizing: #shrinkWrap in the original method. Open it on Smalltalk, expand it and move the scrollbar to see utter confusion!

These are all subclasses of scrollpane, but I have not tested AlansTextPlusMorph, the only other subclass.

For the morphs under discussion, it should be noted that innerBounds is calculated to be bounds minus the scrollbar: innerBounds is used to set the extent of the scroller, the scrolling pane.In the method Morph>>adjustLayoutBounds there is first a correction to the width when hResizing = #shrinkWrap and then later -in Morph>>layoutBounds: the same correction is made once more. innerbounds figures in those calculations directly or indirectly.

Possible fixes (e.g.don't use #shrinkWrap or disable/change ScrollPane>>adjustLayoutBounds) don't really answer your or my questionas to why it was designed that way. In a sense, shrinkWrap does not make sense for the PluggableTextMorph and friends, because they are shrinkwrap by design: the inner text pane is calculated by the PTM to fill itself!