Hi Ken:

Never seen something like this, but if you are distributing an exe, then
you should md5 it so you can detect any change comparing with a saved md5.

This way I've found viruses that changed parts of the code and antiviruses
have cleaned them up, but leaving the exes in a different state than the
original, sometimes even unrunnable.

Best regards

El 28/2/2017 4:58 p. m., "Ken Dibble" <[email protected]> escribió:

> 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
>
>
[excessive quoting removed by server]

_______________________________________________
Post Messages to: [email protected]
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/CAGQ_Ju=-4rm454zcabav02kvmln8dven_mzfhaes2-s4egp...@mail.gmail.com
** 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.

Reply via email to