How do I Create a Custom Property, part 666

[David Burgun]

Hi,

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 mouseUp

This 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 if

But 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 format
>>>that the engine can handle...
>>>The engien gives a damn about empty lines, but YOUR scripts may 
>>>cause trouble in that case...
>>What I mean is that surely it would be better for the "engine" to 
>>expect lines to be *terminated*
>>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