Same code that worked in 6 returns an empty string in the same situation in X. I’ve tried it with chevrons around the field name, quotes, with and without Ω, and the results are the same. The Help implies that it should work just like 6.
The LineItemArray( function assumes that the lines are separated with carriage returns. On OS X, this isn’t always true – sometimes linefeeds are used instead. You can add a lftocr( function so that it will work either way.
lineitemarray(lftocr(array),...)I don’t understand. My line items are distinct fields (Item1, Item2, Item3, …) displayed separately on a form, they are not connected to each other by carriage returns or anything else.
I think you are confusing this with some other function. If you have 3 fields named Field1, Field2, and Field3 containing Gold, Silver, and Bronze respectively then
lineitemarray("FieldΩ","-")
should return Gold-Silver-Bronze.
This sounds like a description of the nthline( function, rather than lineitemarray(
Exactly. Instead it returns “”. I’ve looked at this with several different line items (this is an invoice, and every line of the invoice has several sets of line items). They all do this.
I’m sorry, I obviously wasn’t reading carefully.
Now that I am reading this correctly, I have no idea what the problem is. I have pulled up a test database with line items and the lineitemarray( function works just fine. The only way I can get it to return empty text is if the specified field name doesn’t exist.
Here is a screenshot of my test database, a procedure that uses lineitemarray(, and the result.
David submitted test cases that illustrated the lineitemarray( function failing. It turns out the problem was that it did not work with any separator other than carriage returns. I have fixed this for the next release. @staylor246 did not submit the formula he was using, but I think it must have used a separator other than carriage return. For now, that won’t work.
That appears to be the case, I was using “>”. When I changed that to cr() life was better. Question: is ¶ equivalent to cr() in this case? In every case?
I have some thoughts about terminology here. I was confused about what you were talking about with “separator” in your initial reply, and it turned out you were talking about something else entirely. And now you’re using the same word “separator” in terms of an array, a word which can have many meanings. I think the term “delimiter” has a much more precise meaning in this context, and I would have understood much more quickly what you were talking about if that was the word you used.
In any case, I wish I could say that my problems with this procedure are solved, but there are other issues that I will address in a separate post(s).
One more undocumented difference I discovered. In the code that worked fine in Pan 6, I used chevrons around the field names in my lineitemarray( functions. They returned nothing in Pan X until I substituted quotes around the field names.
Yes. The ¶ symbol is used to stand for carriage return, also known as chr(13) or cr().
In his initial reply, he was also talking about an array, but he had a different function in mind. The nthline( function returns one element from a carriage return separated array.
That doesn’t change my mind about the ambiguity of “separator” or “separated” compared to “delimiter” or “delimited” when talking about these things.
Maybe we have different definitions of the word ambiguity. I can think of only one meaning for separator.