-->
Page 1 of 2

instr and instrrev bug *solved*

PostPosted: Sun Nov 06, 2016 3:29 pm
by Luc Volders
Hi,

As ESP Basic has no 2 -dimensional array's (yet I hope) I was going to make an array that has multiple values in each element for setting RGB values in a neopixel string.
The variable will look like a = "r100 g200 b300"
So for getting the sriings out for putting the right values in the Neopixel commands I would use the instr() command.

Now I think I found a bug or maybe something I do not understand so please have a look at this:

Code: Select alla = "r100 g200 b300"
print a
valg = instr(a, "g")
print valg


This program prints 6 as value of the variable valg which it is supposed to be

Code: Select alla = "r100 g200 b300"
print a
valg = instr(a, "g", 3)
print valg


And this also print 6 as value for valg.
As far as I read in the documentation the 3d parameter tells instr from where to start counting. 3 is in my opinion the 3d letter so the outcome should not be 6.

Now this:

Code: Select alla = "r100 g200 b300"
print a
valg = instrrev(a, "g")
print valg


The outcome is in this case also 6 and it should be counting from the right side backwards so should not be giving 6 as an answer but 9.

Code: Select alla = "r100 g200 b300"
print a
valg = instrrev(a, "g", 3)
print valg


This print a 0 as value for valg.

Something wrong with these commands or am I missing something ???

I am using ESP Basic 3.0.Alpha 59

Luc

Re: instr and instrrev bug

PostPosted: Mon Nov 07, 2016 4:53 am
by ilc
I haven't tested any code, but I'm guessing from reading the docs that there may be some confusion between counting (i.e. position) and searching. It looks as if position is always counted from the first (left) character, and all the third parameter does is change where the search commences (i.e. the position is not referenced to it.) Same for instrrev, all it does is change the direction of the search, everything else is still referenced from the left.

Re: instr and instrrev bug

PostPosted: Mon Nov 07, 2016 10:31 am
by bugs
That is correct - the 3rd parameter sets where the search starts but does not alter the position in the string where the required character is found.
A full explanation and example can be found by looking at the Microsoft VB function
https://msdn.microsoft.com/en-us/library/8460tsh1(v=vs.90).aspx

Regarding the original array with multiple items, it might be easier to use the BASIC "word" function rather than "instr" - from the help file:-
word():

This function returns the nth word in the string, string variable or string expression.

The string delimiter is optional. When it is not used, the space character is the delimiter.

Bla = word( {original string}, {number}, {optional delimiter. Default is space} )

Ex.

word(“The quick brown fox jumped over the lazy dog”, 5) will return “jumped”

Re: instr and instrrev bug *solved*

PostPosted: Mon Nov 07, 2016 2:38 pm
by Luc Volders
I edited the title of the subject in *solved*

It was not a bug but my ignorance.
The 3d parameter is indeed the point where the search starts.

Code: Select alla = "r100 g200 b300"
print a
valg = instr(a, "g", 7)
print valg


Will therefore give a 0 as an answer because the search for the letter g starts at the 7th character and the 'g' is at the 6th position. So no g will be found after the 7th character and the answer = 0.

Took me a while to figure it out but thanks to the posters in this thread I found it.
Thanks guys

Luc