subscript used with non-array variable

[Phenom]

I have a compiled AutoIt program which works sometimes, and sometimes doesn't. When it crashes it says, Line 7749 Error : Subscript used with non-array variable. What are the possible causes for this? It used to work, so I don't think the problem is in the code. I checked the amount of free memory I have and it should be sufficient.

Edited August 16, 2010 by Phenom

[water]

I have a compiled AutoIt program which works sometimes, and sometimes doesn't. When it crashes it says, Line 7749 Error : Subscript used with non-array variable. What are the possible causes for this? It used to work, so I don't think the problem is in the code. I checked the amount of free memory I have and it should be sufficient.

The problem is that you try to access a non-array variable like an array.

I have experienced this kind of problem when you call a function that returns an array on success but an empty string on error (and sets @error).

In this case either check @error after the function call (best choice) or use "IsArray" to check the return value.

[MvGulik]

... check @error after the function call (best choice) or use "IsArray" to check the return value.

Checking for @error value is indirect. Using IsArray() is direct.

Better to use direct checkups. Especially when trying to track down the source of a active problem.

---

Phenom,

Start dropping "If Not IsArray($YourArray) Then Exit 991/992/etc" lines after code line that assign data to that array variable. (or if your running your code in script mode, use "... Exit @ScriptLineNumber")

Look for "$YourArray = ..." and "function(..., Byref $YourArray, ...)" cases.

Edited August 16, 2010 by MvGulik

[water]

Checking for @error value is indirect. Using IsArray() is direct.

Better to use direct checkups. Especially when trying to track down the source of a problem.

I assume a correctly written function that sets @error if an error occurred.

So I think first checking if an error occurred and if @error=0 then process the returned data is good programming practice.

But I could be wrong

[MvGulik]

I assume a correctly written function that sets @error if an error occurred.

So I think first checking if an error occurred and if @error=0 then process the returned data is good programming practice.

But I could be wrong

"good programming practice": I agree.

"assume a correctly written function" on someone else his (unkown) used code. ... Unsafe at best.

[water]

"assume a correctly written function" on someone else his (unkown) used code. ... Unsafe at best.

Sometimes I'm a bit too optimistic

As we haven't seen the OPs code he can either enhance his own functions or use belt and suspenders to be sure he is on the safe side