Function Instr, faulty response since version 2.0.8.2

Zitronenfalter · Joined: 23 Aug 2010 Posts: 12

Hello

The Function Instr in Version 2.0.8.2 shows an incorrect result if the search string is embedded within {} (e.g. "{034}" for the quotation mark).

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

i tested and confirm it is a bug. will have a look at it.

Zitronenfalter · Joined: 23 Aug 2010 Posts: 12

I noticed today that the function INSTR returns zero for a search string consisting of Chr(13)+Chr(10) although this string is in the string to be searched.

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

please post a small example so it can be checked.

Zitronenfalter · Joined: 23 Aug 2010 Posts: 12

Sorry, now I wanted to write a small program but apparently this part of the function works.
But in my "big" program it does not work.
Somehow a local variable containing the search string is changed.
If the search string is global, the function works as it should. But that should not be your problem now.

JC · Joined: 15 Dec 2007 Posts: 586 Location: Cleveland, OH

IN addition to your normal debugging, make sure your Stacks and Framesize are adequate.

JC

Zitronenfalter · Joined: 23 Aug 2010 Posts: 12

I was also thinking of the stack in this context.
But even the increase from 300 to 350 and even more bytes did not bring success. The one new local variable with its two bytes would have to be IMHO with the additional 50 bytes.
For some reason I can't see, this one string variable is empty even though it was previously assigned to Chr(13)+Chr(10).

The used controller (ATmega1284p) should have enough RAM.
If you can rely on the report only approximately, my application currently needs about 7kByte RAM.

I have had problems with such big controllers where the compiler was "swallowed up" by the size.
It even happened sometimes that a program part at one position in the program listing did not work (or better said differently) and moving the program part then delivered the expected flow of the program. I would like to explain this with the fact that there might be a problem with "page-spanning" (IMHO 64kByte) program parts which then only become effective under certain circumstances.
As far as I remember, there was also a problem with a somewhat longer "DO-WHILE-listing". The exit did not work then. But it did after simply moving the program part within the listing.

But as long as I can "circumvent" it, it doesn't bother me.

Zitronenfalter · Joined: 23 Aug 2010 Posts: 12

I could solve the problem now.
The reason was the order of declaration of the two local variables and in consequence the assignment of a byte variable with the return value of a function as dWord.

To my excuse I only want to add that I had improved an older program and through the new BasCom version just stumbled over the error described in the incoming mail and wanted to apply the workaround in form of a string variable.
The error described in the incoming mail still exists, of course.
Here the error was clearly sitting in front of the screen.