Well I just tried it and it works just fine my way. Doing it the way you suggest just addes more lines of code to the script.
Here is sample code to demonstrate:
on mouseUp put empty into myLineList
put myLineList & "Line1" & return into myLineList put the number of lines in myLineList into myLineCount
put myLineList & "Line2" & return into myLineList put the number of lines in myLineList into myLineCount
put myLineList & "Line1" & return into myLineList put the number of lines in myLineList into myLineCount
if line 1 of myLineList = line 3 of myLineList then
beep
end if
end mouseUpThis avoids the if endif on EVERY append operation performed myLineList as discusseed earlier.
To avoid the case where the last line does not have a terminator, you can do this:
if the last character of the last line of myLineList is not return then
put the last line of myLineList & return into the last line of myLineList
end ifBut this only happens if you allow the list to get into that state to start with OR if the list is coming from the IDE (which is what happened yesterday). Also you only need to run this ONCE when the list is first imported into the Script, not every time you need to append a line.
The programmer/scripter is responsible for supplying data to the engine in a formatWhat I mean is that surely it would be better for the "engine" to expect lines to be *terminated*
that the engine can handle...
The engien gives a damn about empty lines, but YOUR scripts may cause trouble in that case...
by a CR *always*. Then it wouldn't have to worry about the case where there is only one line in
the container and nor would the script!
Then we all would have to "re-learn" very hard!!! ;-)
No need to re-learn, it works this way already, see above sample code.
"Hmmm, put "myNewCustomProp" & return after myCustomKeys? That will procude an empty line!
I am sure the user does not want this, so i simply delete the trailing CR when nobody is looking..." :-D
No it doesn't! Try it! See above sample. It prodices exactly one line as expected.
Well, if you (or the engine or whatever) handles it that way, sure, BUT I am saying that if the rule was that each "line" was *always* terminated by a return, then you wouldn't need to do anything special and there would never be a case where the script code would have to be complicated (see above) to append a line.
But it isn't this way... So you better get used to it...
No need to get used to it, it works the way I describe in the sample above.
No, no, this is semantically incorrect! (Sorry for you, but semantics IS my hobby :-D
The sample above works fine - the proof is in the pudding!
LINES are defined by the "linedelimiter" which is in fact the CR.
If we decide (like you suggested) to use the CR as an itemdelimiter, we would not be
able to differ "lines" anymore, because there is NO linedlimiter anymore to differ them...
So we would have to define another linedelimiter first :-)
And that would be the "END OF THE LINES" like we used to know, and therefore not acceptable :-)
I really don't understand what you mean, but as I say the above sample works just fine, so it's a moot point really!
For instance the lines in a text file l are seperate lines and guess what?
In 99.99999999% of cases the seperation character is at the END of a line, not at the start of the next one!
Oh, i never thought about this. Maybe because this is the only "programming"-language i know... ;-)
But the way RR handles it, still sounds very logical to me...
Yes, because it handles the same way, see above sample.
And the end of one line is the beginning of the next one... The old chicken and egg problem... (Attention: humor, joke!!!)
lol. But no, it's always the LAST character of a line, no chicken or eggs to worry about getting roasted or scrambed! (joke)
Wouldn't you agree that the CR Last Method is simpler/easier/better?
No :-D
But simply because it now simply is the way it was for the last 12 years (in the life of the engine)
and i don't know otherwise...
But it works that way anyway!!!!!!!!!!!!! So by definition it's better!!!!!!!!!!!!
And maybe because i know that it is idle to question things that won't change.
(...in the near and distance future... Just like the way the engine handles lines)
So do I, cos it handles them the way I expected them to be handled!!!!! No need to change anything.
All the Best Dave
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
