IDE versus MSG Box - Field Tabstops

[Richard Gaskin]

Geoff Canyon wrote:
> On Wed, Aug 14, 2013 at 6:02 PM, Richard Gaskin wrote:
...
>> If you wrote code expecting the engine to treat incoming values
>> consistently, you risk having unexpected column widths.
>>
>> So we have to ask ourselves:  now that the engine explicitly supports
>> relative values via the tabWidths property, is the "sometimes" rule for
>> setting tabStops a feature or a bug?
>
> It's not a sometimes rule -- it's determinative, and it's a feature.
>
> 1. Item 1 of the tabstops is always absolute.
> 2. If the absolute position of item N of the tabstops > item (N + 1) of the
> tabstops, item (N + 1) is taken as relative (added to the absolute position
> of item N).
> 3. After the last tabstop (item F), additional tabstops are added at
> intervals of item F - item (F - 1) -- or simply item F if there is only one
> item in the list -- until the field runs out of room.

1 and 3 and always consistent, but 2 simply says that sometimes the 
values are treated as absolutes and other times as relative.

In brief, code that expects the values to be treated consistently will 
at some point fail if those values have sufficient freedom of range.

This is presumably why tabWidths was added, and apparently they forgot 
to close this hole with the older token.

But before I file a bug report, let's see if it's worth the time:  has 
anyone ever had code that produced unexpected/unwanted results from this 
inconsistent treatment of the input values of tabStops?

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys