> From: Ben Rubinstein > > It's easier to see with items, and I think it is consistent: > > number of items in "," ---> 1 > number of items in ",," ---> 2 > number of items in ",,a" ---> 3 > number of items in ",,a," ---> 3 > item 2 to 3 of "a,b,c,d" ---> b,c > > If you take this model: > - that the delimiters are not part of the chunk, but serve > only to split text > into two chunks; > - that if there is no text following the delimiter, there is > a chunk before it > not after it; > - and that the delimiter's appearance at the start of text > indicates an empty > chunk before it; > > are there any examples of LC behaviour which are inconsistent with it?
YES. A listbox that has a return at the end of its contents allows the user to select a blank item following the last visible item. When building up the contents of the listbox a line at a time, you have to append the line of text if it is empty, or append a return and the line of text if it is not. Or, you have to append a line of text and a return each time, then remember to go back and remove the trailing return if anything was added. I'm not saying that behavior is necessarily wrong, it's just that there is some precedent for a return at the end implying an empty line. One third way to interpret a list would be to say that any trailing stuff that isn't followed by a delimiter would be ignored entirely. This would be counterintuitive when the delimiter is a printable character (e.g., "a,b,c,d" would ignore the "d"), but has some precedent when the delimiter is a return (some parsers ignore an unterminated last line in a text file). -- Ciao, Paul D. DeRocco Paul mailto:pdero...@ix.netcom.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
