Hi guys,
This does appear to be some type of bug or at least an issue with what is
written in the documentation. From my test it appears if true is set for
the "flag" parameter then it will include empty values from the list AND
mark the delimiter parameter as a multi character delimiter. Below is my
ugly test code below modified from what Dave created earlier. I'll submit a
ticket for this when I get a chance.
<cfscript>
x = [];
x[1] = {
__notes:"Listtoarray uses both period and comma as delimeter",
_list:"asdf,qwer.something",
_delimiter:".,",
_flag:"na",
value:listToArray("asdf,qwer.something", ".,")
};
x[2] = {
__notes:"True passed to 'empty flag' and now function acts like third
param is for 'multi char'",
_list:"asdf,qwer.something",
_delimiter:".,",
_flag:true,
value:listToArray("asdf,qwer.something", ".,", true)
};
x[3] = {
__notes:"False passed to third param and we're back to we would expect.
It does not act like a 'multi char' flag.",
_list:"asdf,qwer.something",
_delimiter:".,",
_flag:false,
value:listToArray("asdf,qwer.something", ".,",false)
};
x[4] = {
__notes:"Test for multichar with third param as true. Yup, that's what
it is doing.",
_list:"asdf.,qwer.,something",
_delimiter:".,",
_flag:true,
value:listToArray("asdf.,qwer.,something", ".,", true)
};
x[5] = {
__notes:"Now lets see if third param acts like an 'empty flag' which is
what the documentation says it should be doing.",
_list:"asdf,qwer.,something.,",
_delimiter:".,",
_flag:true,
value:listToArray("asdf,qwer.,something.,", ".,", true)
};
x[6] = {
__notes:"Now lets see if third param acts like an 'empty flag' which is
what the documentation says it should be doing.",
_list:"asdf,qwer.,something.,",
_delimiter:".,",
_flag:false,
value:listToArray("asdf,qwer.,something.,", ".,", false)
};
WriteDump(var:x, label:"Test for ListToArray function");
</cfscript>
On Friday, September 19, 2014 11:36:15 PM UTC-5, [email protected] wrote:
>
> It looks to me like passing either true or false as the third argument to
> listToArray() causes it to return incorrect results when more than one
> character is passed as the delimiter. Note that I'm not talking about the
> fourth parameter (multiCharacterDelimiter in ACF docs), which isn't
> documented as supported for OBD.
>
> Here's a simple test:
>
>> <cfscript>
>> x = [];
>> x[1] = {notPassed=listToArray("asdf,qwer", ".,")};
>> x[2] = {truePassed_1=listToArray("asdf,qwer", ".,", true)};
>> x[3] = {truePassed_2=listToArray("asdf,qwer", ",.", true)};
>> x[4] = {truePassed_3=listToArray("asdf,qwer", ",", true)};
>> x[5] = {truePassed_4=listToArray("asdf.qwer", ".", true)};
>> x[6] = {falsePassed=listToArray("asdf,qwer", ".,", false)};
>> </cfscript>
>> <cfdump var="#x#" label="">
>>
>
> Result is this in Open BlueDragon 3.1, build date 2014-03-30 22:33:45 GMT:
>
>
> As you can see, in both cases where more than one character is passed for
> the delimiter, passing true for the third argument acts as if the ACF-only
> multiCharacterDelimiter fourth argument was passed true, so only the entire
> delimiter string is honored, instead of honoring any of the characters in
> it.
>
> Works as expected in ACF, where either passed delimiter is honored, and
> the third argument controls whether to honor empty list items, as
> documented.
>
> Am I missing something obvious?
>
--
--
online documentation: http://openbd.org/manual/
http://groups.google.com/group/openbd?hl=en
---
You received this message because you are subscribed to the Google Groups "Open
BlueDragon" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
