Added a bug report: https://pharo.fogbugz.com/f/cases/19884/Rubric-should-not-use-SmallInteger-m... Indeed changing this in Rubric is the best option. #maxVal is used in more places in Rubric, On Wed, Mar 29, 2017 at 5:10 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 29 Mar 2017, at 17:01, Andrei Chis <chisvasileandrei@gmail.com> wrote:
On Wed, Mar 29, 2017 at 2:12 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
why does rubric checks for maxVal at first instance?
This is the problematic code for Spotter:
RubAbstractTextArea>>#drawingBounds ^ (self scrollPane isNil or: [ self wrapped ]) ifTrue: [self innerBounds] ifFalse: [ self innerBounds topLeft extent: SmallInteger maxVal @ SmallInteger maxVal ]
looks like heâs trying to get an incredible huge drawing area. I would just extract that to a RubAbstractTextArea class>>#maxExtent class method, and with constant numbers, as Eliot suggested.
Esteban
On 29 Mar 2017, at 14:07, Andrei Chis <chisvasileandrei@gmail.com> wrote:
Hi,
Right now rubric relies on 'SmallInteger maxVal' to set the drawing bounds when a size is not set for the editor. This has some side-effects, like the text in Spotter not appearing on 64 bit given that some drawing methods from the graphical backend seem to expect 32 bit ranges. We can fix this by introducing #maxVal32 or maybe there could be some range checks in the canvas. Comments?
Cheers, Andrei