You're right (IMHO) - the original reason I struggled to understand this
was not the trailing delimiter issue, but rather the incorrect handling
of 'inverted' ranges in a chunk expression.
There are a variety of possible valid interpretations of a inverted
range (my opinion is that these are, in order):
1. normalize the order (as you suggested)
(i.e. put xxx into line 3 to 2 ... would be equivalent to put xxx
into line 2 to 3 ...)
2. take the "from" part of the chunk range expression, and stop there
(i.e. put xxx into line 3 to 2 ... would be equivalent to put xxx
into line 2 ...)
3. cause an error !!??
What it does now is (I think) equivalent to
put xxx before line 3 of ....
Which is consistent to viewing
put xxx into (chunk) of (container)
as being equivalent to
put xxx before line tFROM of container
repeat with i = tFROM to tTO of container
delete line i of (the original) container
end repeat
So I can just about see that there is some consistency in the current
method - but it is highly unintuitive and hard to predict.
-- Alex.
On 17/03/2012 20:31, Geoff Canyon wrote:
This seems wrong to me. Regardless of how the engine interprets a chunk
expression, a command of the form put<something> into<some chunk> should
result in<some chunk> containing<something> So the fact that you are
putting "b" into something should result in that thing being "b," where
here the result is "ba" further, there's the fact that after the command,
the chunk is still empty. So:
put "a"& cr into t;put "b" into line 2 to -1 of t;put line 2 to -1 of t
is empty
puts true. I did a quick check to take the negative line number out of
this. If you have a field with contents:
a
b
c
then put line 2 to 1 of fld 1
puts empty, and put "x" into line 2 to 1 of fld 1
results in line 1 of the field being "xa"
again, this feels wrong. "line 2 to 1" of something should be an error. I
can see the value of having it return empty when you are getting it, but
putting something into it results in bad behavior.
Another way of addressing this would be to say that chunk expressions
always understand and follow proper order. So "line 2 to 1" would be the
same as "line 1 to 2" Under that scenario, put "x" into line 2 to 1 of fld
1 would result in the field containing:
x
c
and the original problem:
put "a"& CR into t; put "b" into line 2 to -1 of t; put t
would put
b
which seems like a much more reasonable (and predictable) outcome.
gc
On Sat, Mar 17, 2012 at 11:33 AM, J. Landman Gay
<jac...@hyperactivesw.com>wrote:
On 3/17/12 8:16 AM, Alex Tweedly wrote:
This code
put "a"& CR into t; put "b" into line 2 of t; put t
produces (as I would expect)
a
b
BUT
put "a"& CR into t; put "b" into line 2 to -1 of t; put t
produces
ba
Why should adding the "to -1" change this to put the new data before
what was there before ?
It's because of how the engine ignores trailing delimiters. The variable t
contains only one line, so "line 2 to -1" evaluates to "line 2 to 1".
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
______________________________**_________________
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<http://lists.runrev.com/mailman/listinfo/use-livecode>
_______________________________________________
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
_______________________________________________
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
