"Scan String For Tokens": Is this a bug?

[CDL]

Hi,

I'm using LabVIEW 2011 (PDS).

In Scan String For Tokens.vi, if one of my operators is at the end of the input string it returns -1 for offset past token, where I would expect it to be equivalent to the input string length.

Using the example from the online help, "This is a testLabVIEWstring", if I add "ring" to the list of operators, I'd expect the penultimate iteration to return Token String = "ring" (which it does) and offset past token = 27 (cf Match Pattern.vi) not -1.

Regards

Conway Langham

[crossrulz]

From the LabVIEW help:

---

offset past token identifies the point in the input string immediately following the most recently found token and any trailing delimiters. Any subsequent scanning of the same input string should begin at this offset. If offset is less than 0 or greater than the number of characters in input string, or if the end of the string was reached, offset past token is –1.

---

[CDL]

From the LabVIEW help:

---

If the function reaches the end of input string without finding any valid operator, token index returns –2.

---

As I understand it, the correct way of detecting the end of the input string is when token index returns –2. In my example the offset input  is between 0 and the number of characters in input string, and so offset past token should not return -1!

Conway

[Darin.K]

I'll admit that this is not one of my favorite functions, but the key phrase from the help is here:

...if the end of the string was reached, offset past token is –1.

[CDL]

Okay, I guess I'm splitting hairs here. What I think should be the case is that "...if the end of the string was exceeded, offset past token is –1." The situation of reaching the end of a the input string and finding a token is not an error and so the VI should not return -1

There is an ambiguity here with offset past token returning -1, and an incompatabilty with other VIs (such as Match Pattern.vi). What's more, this ambiguity is redunants as scanning passed the end of the input string is uniquely indicated by token index returning -2.

Conway

[Darin.K]

You will get no argument from me about what the desired behavior should be.  That function is annoying and I have to read and reread the context help the few times I use it.  Personally I think this is a bad sign and partially stems from the differences you point out with the other functions.

As to the current behavior, it appears to be by design and working as planned (for better or, ahem, worse.