Invalid subscript reference (config problem?) 1

[Paulm52]

I'm having VFP problems with code using arrays. On one machine, the following code runs successfully:

DIMENSION array[20]

FOR x = 1 TO 5
array[x] = RAND()
ENDFOR
clear

?? array[1]
?? array[2]
?? array[3]
?? array[4]
?? array[5]
?

FOR i = 1 TO ALEN(array)
?? array && sometime generates an error
ENDFOR
?

However, on my normal development system, I get a "Invalid subscript reference (Error 31)" message any time I refer to array. In the debugger, everything runs correctly; I can see that I get a good value from the ALEN(array) call. But the next line? Error!

One thought that I've had is that there were differences in the configuration or settings. So I deleted FOXUSER.DBF (no change) and compared the output of DISPLAY STATUS (no difference between the two systems).

Both systems running VFP 9.0 SP2, Windows 7 SP 1. So what could be different in VFP between my two systems?

 

[EzLogic]

wierd.
i am not getting any error.

is the variable Array "array" being changed or re-declared somehow?

try changing the variable name to myArray or something. don't know if that would help at all, i think ARRAY is a keyword

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Paulm52]

No, the array name isn't significant. I've renamed the array a number of ways. And I reduced the program to this sample that fails on one machine.

I've restarted VFP and rebooted my machine as well. If I get desperate I'll re-install VFP. But I really don't want to go through that effort.

Thanks anyway.

 

[Olaf Doschke]

If this code fails as it is, there's got to be something wrong outside of VFP, eg wrong C runtime version. Maybe hardware, flaky RAM?

ALEN will not give any more than the number of elements, if you were addressing a two dimensional array with that number of elements you surely would fail, as you'd then need to use ALEN(array,1) to get the row count, but that's not the case here. And elements you don't set are inited as .f., like any variable. And that is displayed by your code.

Bye, Olaf.

 

[Olaf Doschke]

The only thing making i something out of the range of 1..ALEN would be, if there is a table/cursor/view/alis open with a field named i, too. See

http://msdn.microsoft.com/en-us/library/addt8a5f(v=vs.80).aspx

Bye, Olaf.

 

[DSummZZZ]

You may also want to try using longer/better/more unique variables for the indexes. Plain old 'i' may get VFP confused with a work area, or you have may accidentally used 'i' somewhere else (not that I have ever done that) then re-referenced it here.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Paulm52]

Yes, that does it! An index as simple as "i" apparently conflicts with internal Visual FoxPro variables. If you are right and "i" conflicts with a work area, that feature must be a holdover from older versions of FoxPro.

Thanks so much. I won't use single-character variables again in FoxPro!

 

[Dan Freeman]

A holdover? It's a core behavior of the language!

 

[DSummZZZ]

Aaahhhhh... remember the good old days when Fox could have a total of - what was it, 10 open files at a time? 1 or 2 tables and their associated index files? And we used numbers or letters for work areas?
Ugh.

Anyway, glad that cured the issue. I got out of the habit of using terse variable names a long time ago. I caused way too much grief. Even during simple command window testing.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm