Hard-Coded Scalar Value Substituted at Run Time

I swear, my code is haunted.

I have some code in a subclass of my custom-built list control class. I provide enough code here to indicate the context, but I don't think I need to explain its purpose to illustrate what has just happened:

FOR m.x = 1 TO ALEN(THISFORM.oMail.aSortList,1) ** 2/28/17: ** ** On this date, a user had an "Array dimensions are invalid" ** error at this point in the code. However, the trace gave the ** offending line of code as follows: ** ** thekey = THISFORM.oMail.aSortList(m.x,10) ** ** The parent code doesn't contain any lines like that, at all. ** The array has 5 hard-coded columns, not 10. It has always ** had 5 columns since I wrote this code many years ago. ** There is NO WAY that the hard-coded scalar value of 5 ** in this code could be changed to 10. That is really, really, ** REALLY weird.

** This is the actual code:

* Find the corresponding row in the temporary storage array. thekey = THISFORM.oMail.aSortList(m.x,5)

** See? Not 10. It's 5.

findrow = ASCAN(THISFORM.aTmpSort,thekey,-1,-1,5,15)

IF findrow > 0 * We found it. Copy the temporary storage array row back to the * listcontrol's RowSource.

FOR m.y = 1 TO ALEN(THISFORM.aTmpSort,2) THIS.aItemList(therow,m.y) = ; THISFORM.aTmpSort(findrow,m.y) ENDFOR

* We use this to control which aItemList row to populate because * I'm not sure the two arrays will have an equal number of rows * in all cases. (They SHOULD because the RemoveAddress() method * truncates both the RowSource and last-name-sorted arrays, but * just in case...) therow = therow + 1 ELSE * The row absolutely should be there. RETURN .F. ENDIF ENDFOR

Now, this particular user uses this feature and executes this code quite frequently. But today, somehow, at run time, a hard-coded scalar value of 5 was replaced with 10. This crashed the program, which emailed me as a result, so I have the trace.

I can't reproduce it. So it does not appear that the last compile messed something up. Instead, something magically changed that number this ONE TIME while the code was executing.

Is this really the proverbial cosmic ray flipping a bit?

Has anyone ever seen anything like this?

If not, why do these things only happen to me?

Thanks for any thoughts.

Ken Dibble www.stic-cil.org