>>>>>Hi Gang!
>>>>>
>>>>>My fellow colleague at work has this problem. He has this in some code
>>>>>
>>>>>

>>>>>PROCEDURE getArrayElement
>>>>>      PARAMETERS lnElement
>>>>>      pcTheData = laWarnLbl[lnElement]
>>>>>      RETURN pcTheData
>>>>>ENDPROC
>>>>>

>>>>>
>>>>>The above snippet of code is giving me the “invalid subscript reference” error on the “pcTheData = laWarnLbl[lnElement] line.
>>>>>
>>>>>The value of lnElement at this point is 1.
>>>>>
>>>>>And laWrnLbl is dimensioned to 6.
>>>>>
>>>>>Thanks
>>>>
>>>>If you have a field called lnElement in the active table, and it has a value greater than 6, you will get this error. I strongly advise you to alter this routine so that it uses LPARAMETERS. It should receive the array as a parameter too. It should declare pcTheData LOCAL or not even use pcTheData at all. I'd write it this way.
>>>>
>>>>

getArrayElement.prg
>>>>LPARAMETERS lnElement,taArray
>>>>EXTERNAL ARRAY taArray && prevents compiler error.
>>>>RETURN taArray[m.lnElement]

>>>>
>>>>and I'd call it like this
>>>>

?GetArrayElement(5,@laWarnLbl)

>>>
>>>This will probably answer Dimitry's question, but I have another question - why call a one-line procedure?
>>
>>1 - standardization, 2 - expansion, 3 - a single point of maintenance, 4 - readability.
>
>Mike
>I agree on expansion and perhaps, but not surely, on standardization and a single point of maintenance, but I submit that doing something in line is more readable than calling a function that does it.

I did not "design" the routine. I'm just showing all that is wrong with it.

I disagree with inline makes things readable. type("alen(latest)")#"N" is inline and is not readable unless you have either seen the code before or you puzzle it out. Having to puzzle it out is not readable. I cannot remember it when I need to write it again and had to go look it up. I much prefer IsArray(@latest)