Hi all, I think I found a bug in the TableLayout when used in connection with #disableLayout.
Example to reproduce:
m := Morph new. m changeTableLayout; listDirection: #rightToLeft; wrapCentering: #center. n := Morph new color: Color red. n visible: false; disableLayout: true. m addMorph: n.
m fullBounds.
Expected output:
Same as [n fullBounds].
Actual output:
Error: subscript is out of bounds: 1 in TableLayout >> #computeExtraSpacing:in:horizontal:target:
Problem:
arrangement is nil.
In #layout:in:, cells is 0@0->#(). This is an invalid state, isn't it?
The bug could have occurred because the initial #hasSubmorphs check in #layout:in: does not work if the only submorphs have #disableLayout set.
Would it be an appropriate solution to exit the method after step 1, if cells value isEmpty?
I never have worked with LayoutPolicies in detail, thus I likely only see a small part of the problem. I also don't see why listDirection #leftToRight is handled fundamentally differently than #rightToLeft. Any help is appreciated! :-)
Best,
Christoph
Fixed. Thanks! :-)
Best, Marcel Am 03.04.2020 20:31:09 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi all, I think I found a bug in the TableLayout when used in connection with #disableLayout.
Example to reproduce: m := Morph new. m changeTableLayout; listDirection: #rightToLeft; wrapCentering: #center. n := Morph new color: Color red. n visible: false; disableLayout: true. m addMorph: n.
m fullBounds.
Expected output: Same as [n fullBounds].
Actual output: Error: subscript is out of bounds: 1 in TableLayout >> #computeExtraSpacing:in:horizontal:target:
Problem: arrangement is nil. In #layout:in:, cells is 0@0->#(). This is an invalid state, isn't it? The bug could have occurred because the initial #hasSubmorphs check in #layout:in: does not work if the only submorphs have #disableLayout set. Would it be an appropriate solution to exit the method after step 1, if cells value isEmpty?
I never have worked with LayoutPolicies in detail, thus I likely only see a small part of the problem. I also don't see why listDirection #leftToRight is handled fundamentally differently than #rightToLeft. Any help is appreciated! :-)
Best, Christoph
Thank you! :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Samstag, 4. April 2020 11:10:36 An: gettimothy via Squeak-dev Betreff: Re: [squeak-dev] [BUG] TableLayout & #disableLayout
Fixed. Thanks! :-)
Best, Marcel
Am 03.04.2020 20:31:09 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi all, I think I found a bug in the TableLayout when used in connection with #disableLayout.
Example to reproduce:
m := Morph new. m changeTableLayout; listDirection: #rightToLeft; wrapCentering: #center. n := Morph new color: Color red. n visible: false; disableLayout: true. m addMorph: n.
m fullBounds.
Expected output:
Same as [n fullBounds].
Actual output:
Error: subscript is out of bounds: 1 in TableLayout >> #computeExtraSpacing:in:horizontal:target:
Problem:
arrangement is nil.
In #layout:in:, cells is 0@0->#(). This is an invalid state, isn't it?
The bug could have occurred because the initial #hasSubmorphs check in #layout:in: does not work if the only submorphs have #disableLayout set.
Would it be an appropriate solution to exit the method after step 1, if cells value isEmpty?
I never have worked with LayoutPolicies in detail, thus I likely only see a small part of the problem. I also don't see why listDirection #leftToRight is handled fundamentally differently than #rightToLeft. Any help is appreciated! :-)
Best,
Christoph
squeak-dev@lists.squeakfoundation.org