To follow up from yesterday evening, now that I'm back at work:

The code in question is a FOR ... ENDFOR loop that iterates an array,

with the loop limiting value being the number of rows in the array,

and there is nothing within that loop that removes or adds rows or

columns to the array.

It's just:

FOR m.x = 1 TO ALEN(THISFORM.oMail.aSortList,1)

thekey = THISFORM.oMail.aSortList(m.x,10) && "array dimensions invalid"

** More inoffensive code here.

ENDFOR

As I've said, I can't reproduce this error myself but I've seen it

reported by my error handler twice in two days. So I don't know if

the iteration failed on the first row or some later row of the array.

As I mentioned earlier, my initial assumption that the array was

supposed to have 5 columns was incorrect, because I was looking at

the wrong control.

I've now verified that in this case, when the problem code executes,

this array can only contain 10 columns:

1. It is a predefined property of the oMail object (based on the

Custom class, and defined in a .prg file) and is DIMENSIONed as (1)

at the outset.

2. It is then populated by a SELECT [10 specified fields] FROM

[variable table/cursor] ... INTO ARRAY expression with no WHERE clause.

3. Although the name of the FROM table or cursor is variable, the

specified fields are not, and the expression does not use AS clauses

to change the names of the result fields or supply default values for

them. Therefore, if a specified field did not exist in the FROM

table, an error would be generated at that point. No such error occurs.

4. It is not possible for the FROM table to contain no records when

the offending code executes, because in that case the code that

generates the FROM table would display a message for the user stating

that the query produced no results and all of the related controls on

the form would be disabled. As a result, the method containing the

SELECT ... INTO ARRAY expression would not be called, the list

control's array rowsource would contain no records, and the list

control's sort method, where the error occurs, would not be called.

So I am confident that the array can only have 10 columns (no more

and no less) at the point where the error is generated.

Thus the only "possible" sources of an "array dimensions invalid"

error, if the error did indeed occur on the line indicated by the

trace, would be:

1. The SELECT ... INTO ARRAY expression somehow generated fewer

columns than were specified in its field list.

2. The user was somehow able to induce one of the disabled GUI

controls to somehow call the sort method when there was no data to sort.

3. ALEN() returned an incorrect result as to the number of rows in

the array during the iteration loop.

All of those things should be impossible.

The third possibility is that the trace provided by ASTACKINFO() is

wrong. In my application I frequently do see very strange things with

error traces, such as several levels of code that should be in the

stack not being reported. I have also seen, in the debugger, that

errors don't necessarily "surface" immediately and the line of code

that generates them may not be the line on which the debugger stops.

There could also be something wrong with my assumptions regarding how

to read a trace. In the case of the issue I've been talking about,

the trace contains the following lines:

Level: 5 Program File: c:\cil data 2\genmaillst.sct Module/Object:

genmaillst.listdisplay.resortlistbox Source File: c:\cil data

2\genmaillst.sct Line Number: 86 Line Contents: thekey =

THISFORM.oMail.aSortList(x,10)

Level: 6 Program File: c:\stic foxpro framework\base

classes\sticbase.vct Module/Object:

genmaillst.listdisplay.error Source File: c:\stic foxpro

framework\base classes\sticbase.vct Line Number: 23 Line Contents:

DO FinalSTICError WITH 0, LINENO(1), theprogram, MESSAGE(1), ""

I read this as: "When the line of code at Level 5 was executed, the

ERROR() method of the object that contains that code was triggered,

as shown in Level 6. Therefore, the error occurred in the stated line

of code in Level 5."

Of course, the way to handle this is to add code to test the size of

the array before trying to iterate it, which I have now done. But I

am still at a loss to understand how the error could occur.

Thanks.

Ken

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/EE.66.16480.C2F48B85@cdptpa-omsmta02

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.