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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
