Dan
Seems to work normally. The space is taken into account as part of the item
which is correct and which appears before line 2 of fld 3.
Or, im wrong and the way words are handled in RR is incorect ;)
Word 2 of "this is, a string" -- since when is a comma part of a word in the
english language
Recently, Dan Shafer wrote:
> OK, I think I've uncovered an anomaly in the way Rev handles/parses
> list items that cost me about four hours of work last night. I want to
> confirm that: (a) I'm right; and (b) this is a bug before I go any
> further.
>
> Here's a recipe that demonstrates the anom
A list should be seen as a comma-delimited data container where commas
separate data elements. Spaces after commas should not be significant.
They aren't in any other language I know of that processes list data
structures. a="1",b="2" and a="1", b="2" should be identical. In Rev,
they are not.
Dan Shafer wrote:
A list should be seen as a comma-delimited data container where commas
separate data elements. Spaces after commas should not be significant.
They aren't in any other language I know of that processes list data
structures. a="1",b="2" and a="1", b="2" should be identical. In Re
Dan,
It appears to me that you're hitting the difference between strings and
lists. The native data type in Rev is a string, and if you want it to
be treated specially because it follows some sort of list syntax,
you'll need to script that behavior. Otherwise you would have the
opposite effect-
On Sep 15, 2004, at 6:03 PM, Brian Yennie wrote:
Dan,
It appears to me that you're hitting the difference between strings
and lists. The native data type in Rev is a string, and if you want
it to be treated specially because it follows some sort of list
syntax, you'll need to script that behavio
At 22:40 15/09/2004 -0500, J. Landman Gay wrote:
Except in other xtalk languages, including HyperCard where the custom
started. ;)
"Items" are everything in between commas (or whatever the current
delimiter is.) That includes carriage returns too.
but with one exception:
There can be a blank it
Hmm... that explains the strange behavior of lines too.
If I set up a field as a list box with records from a database:
put empty into x
revMoveToFirstRecord q
repeat for revNumberOfRecords(q) times
put revDatabaseColumnNumbered(q, 1) & the lineDelimiter after x
revMoveToNextRecord q
end repeat
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 o
