At 09:50 16/09/2004 -0400, Frank D. Engel, Jr. wrote:
Hmm... that explains the strange behavior of lines too.
If I set up a field as a list box with records from a database:
......
Which works as I wish it to. So the list box field looks at that empty line as being a valid, usable line, but the other commands do not?
Not sure just how the list box looked at it, but your description sounds convincing.
Is there a reason why this is also considered consistent?
Yes, kind of.
Forget, for the moment, that you're trying to parse some text - in fact, forget about Rev for a moment. If you took any normal text file on most computers, the last character would be a <cr> (or equivalent). If you asked 99.99% of users "what's the last line in this file?" they'd tell you it was the sequence of characters up to and including that <cr> (though most of them wouldn't really consider the fact that there was a <cr> there, many wouldn't even be aware there was).
None of them would tell you the last line was a blank line !
So for normal text processing of normal text files, Rev gives you the behaviour expected by most everyone.
But if you look at it from a programmer's viewpoint, then you do indeed run into the fact that it is (in some sense) inconsistent.
This difference in viewpoints means that there's no "100% correct" answer for everyone - and I think Rev (presumably following all the other xTalks) has made a reasonable choice. But it does take some care to avoid "fragile" coding.
I've seen a number of example scripts that did something like
put empty into myVar
repeat for (some circumstances)
if (some condition) then put (someVar) & comma after myVar
end repeat
delete the last char of myVar -- remove extra trailing commawhich is OK *only* if you know the last item was not empty (i.e. usually, only if empty items are not valid in context).
-- Alex. -- Alex.
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
