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
_______________________________________________
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/06.EE.03423.31E95B85@cdptpa-omsmta01
** 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.
Author: Fernando D. Bozzo
Posted: 2017-02-28 10:22:23 Link
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" <krdibble@stny.rr.com> 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: 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/CAGQ_Ju=-4rm454zcAbaV02kVMLN8dVeN_mZfhaeS2-s4eGPUtQ@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.
Author: Tracy Pearson
Posted: 2017-02-28 15:24:24 Link
Fernando D. Bozzo wrote on 2017-02-28:
> 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" <krdibble@stny.rr.com> 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.
>>
Ken,
I've seen this when I have had a second function/procedure in a PRG based class of the same name. The second one runs, not the first.
I've also seen strange things happen when classes are based off different classes with the same name from different libraries. It was something odd that way. It's been a long time.
Tracy Pearson
PowerChurch Software
_______________________________________________
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/001601d29209$09375d70$1ba61850$@powerchurch.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.
Author: Ken Dibble
Posted: 2017-03-01 15:33:22 Link
>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.
That's a really good idea.
As it turns out, I'm embarrassed to say, the line of code reported in
the trace does exist, in a virtually identical list control subclass
on the same form (one overlays the other exactly). I wasn't paying
attention to the name of the control in which the error occurred.
There are actually 10 columns in the array in this method.
So what actually happened is that somehow, between:
FOR m.x = 1 TO ALEN(THISFORM.oMail.aSortList,1)
and
thekey = THISFORM.oMail.aSortList(m.x,10)
somehow the length of the array got truncated.
Now, there is NO other code between those two lines, so
ALEN(THISFORM.oMail.aSortList,1) would have had to return an
impossible result for the next line to fail.
I have seen this on a few occasions when iterating arrays, but I
remain mystified as to how it could happen.
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/F5.B6.16480.32E37B85@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.
Author: Tracy Pearson
Posted: 2017-03-01 19:21:23 Link
Do you have a timer in your app?
Or a bindevent() that may have stopped execution between those lines of code?
On March 1, 2017 4:33:22 PM EST, Ken Dibble <krdibble@stny.rr.com> wrote:
>
>>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.
>
>That's a really good idea.
>
>As it turns out, I'm embarrassed to say, the line of code reported in
>the trace does exist, in a virtually identical list control subclass
>on the same form (one overlays the other exactly). I wasn't paying
>attention to the name of the control in which the error occurred.
>
>There are actually 10 columns in the array in this method.
>
>So what actually happened is that somehow, between:
>
>FOR m.x = 1 TO ALEN(THISFORM.oMail.aSortList,1)
>
>and
>
>thekey = THISFORM.oMail.aSortList(m.x,10)
>
>somehow the length of the array got truncated.
>
>Now, there is NO other code between those two lines, so
>ALEN(THISFORM.oMail.aSortList,1) would have had to return an
>impossible result for the next line to fail.
>
>I have seen this on a few occasions when iterating arrays, but I
>remain mystified as to how it could happen.
>
>Ken
>
>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
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/61A974A9-E3EB-496F-A6FF-7A89367F044A@powerchurch.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.
Author: Ken Dibble
Posted: 2017-03-01 21:05:57 Link
>Do you have a timer in your app?
Yes, there's a timer running at the global level to monitor user
activity and shut down the application if it remains idle for a long
period of time. The timer code does not interact with the object
directly, though it will trigger a routine that closes the window
that contains the object if a shutdown proces is started. But the
error did not occur within such a shutdown process.
There's no DOEVENTS in the loop I described, so I would expect that
the FOR .. ENDFOR loop would complete a full iteration before being
interrupted by anything ultimately triggered by the timer.
I do know that VFP sometimes only appears to "become aware" of states
that have changed during a loop when execution gets to the "bottom"
of the loop.
I don't think there's any code within the loop that could remove rows
from the array--I'm aware that's a big no-no, but I will double
check it tomorrow at work.
>Or a bindevent() that may have stopped execution between those lines of code?
No, no bindevents().
Thanks.
Ken
>On March 1, 2017 4:33:22 PM EST, Ken Dibble <krdibble@stny.rr.com> wrote:
> >
> >>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.
> >
> >That's a really good idea.
> >
> >As it turns out, I'm embarrassed to say, the line of code reported in
> >the trace does exist, in a virtually identical list control subclass
> >on the same form (one overlays the other exactly). I wasn't paying
> >attention to the name of the control in which the error occurred.
> >
> >There are actually 10 columns in the array in this method.
> >
> >So what actually happened is that somehow, between:
> >
> >FOR m.x = 1 TO ALEN(THISFORM.oMail.aSortList,1)
> >
> >and
> >
> >thekey = THISFORM.oMail.aSortList(m.x,10)
> >
> >somehow the length of the array got truncated.
> >
> >Now, there is NO other code between those two lines, so
> >ALEN(THISFORM.oMail.aSortList,1) would have had to return an
> >impossible result for the next line to fail.
> >
> >I have seen this on a few occasions when iterating arrays, but I
> >remain mystified as to how it could happen.
> >
> >Ken
> >
> >
>--
>Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
[excessive quoting removed by server]
_______________________________________________
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/6E.8A.16480.A7B87B85@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.
Author: Ken Dibble
Posted: 2017-03-02 10:58:20 Link
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.
Author: Fernando D. Bozzo
Posted: 2017-03-02 11:24:43 Link
Hi Ken,
Seems a difficult one to trace, but just in case I give you some ideas
based on personal experience with strange errors:
* The info collected on the error rutine, put it in a try/catch that adds
info to a var in a step by step basis, so you later can log it to a file.
Must be bomb proof. I've once found an error there when iterating tge stack
array, with some fields that normally are null but somerimes are not. In
any case, an error there must not hide the real error.
* Do not trust UI controls to call or not a method, add validation in the
methods called from UI so even if you call them from VFP command line, if a
condition is noot meet, the method is not executed. Normally can be done an
enabled_funtionallity() like method that can be used by the UI to
enable/disable controls and the same method can be used on the business
methods for the same goal.
In the worst situation, you can generate log info in real time while the
user is working, and save it into a table with info about controls used
(important events like click), screens loaded/unloaded, some meaning
variables and timer events may be, to have some context about executed
order.
Analyzing it later can give you some inside about how the user interacts
with your app.
Once, many years agi, a user notified a bug on which when loading the main
screen all comboboxes where blank.
Tired of not finding the bug days later I did go with the user to watch him
while entering in the app..... And found that the user while the app was
loading did hit enter, enter, enter, enter,....., many times to bypass the
log screen, but all that enter keystrokes where present in the keyboard
buffer, what caused the comboboxes to not show their default options.
Solution was a clear typeahead before showing the UI :D
El 2/3/2017 5:58 p. m., "Ken Dibble" <krdibble@stny.rr.com> escribió:
> 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
>
>
[excessive quoting removed by server]
_______________________________________________
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/CAGQ_JumxDUsGtPS3WpE0g8GMKN66Wa4PE3WcfPYwkYi2Ptwtgg@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.
Author: Tracy Pearson
Posted: 2017-03-02 11:47:41 Link
Hi Ken,
You may want to use SET COVERAGE at the beginning and turn it off at the end of the method that errors, and add that log, of it exists to your error logging. You'll see what lines for called and which iteration it was on.
Sometimes, forgetting to LOCAL a variable changes it in a function called later.
Tracy
On March 2, 2017 12:24:43 PM EST, "Fernando D. Bozzo" <fdbozzo@gmail.com> wrote:
>Hi Ken,
>
>Seems a difficult one to trace, but just in case I give you some ideas
>based on personal experience with strange errors:
>
>* The info collected on the error rutine, put it in a try/catch that
>adds
>info to a var in a step by step basis, so you later can log it to a
>file.
>Must be bomb proof. I've once found an error there when iterating tge
>stack
>array, with some fields that normally are null but somerimes are not.
>In
>any case, an error there must not hide the real error.
>
>* Do not trust UI controls to call or not a method, add validation in
>the
>methods called from UI so even if you call them from VFP command line,
>if a
>condition is noot meet, the method is not executed. Normally can be
>done an
>enabled_funtionallity() like method that can be used by the UI to
>enable/disable controls and the same method can be used on the business
>methods for the same goal.
>
>In the worst situation, you can generate log info in real time while
>the
>user is working, and save it into a table with info about controls used
>(important events like click), screens loaded/unloaded, some meaning
>variables and timer events may be, to have some context about executed
>order.
>Analyzing it later can give you some inside about how the user
>interacts
>with your app.
>
>Once, many years agi, a user notified a bug on which when loading the
>main
>screen all comboboxes where blank.
>Tired of not finding the bug days later I did go with the user to watch
>him
>while entering in the app..... And found that the user while the app
>was
>loading did hit enter, enter, enter, enter,....., many times to bypass
>the
>log screen, but all that enter keystrokes where present in the keyboard
>buffer, what caused the comboboxes to not show their default options.
>Solution was a clear typeahead before showing the UI :D
>
>
>El 2/3/2017 5:58 p. m., "Ken Dibble" <krdibble@stny.rr.com> escribió:
>
>> 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
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
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/68E79853-69AE-4239-AB4B-30FA1E4B5B65@powerchurch.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.
Author: Peter Cushing
Posted: 2017-03-02 11:57:13 Link
On 02/03/2017 16:58, Ken Dibble wrote:
> <snip > 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.
What I usually do in situations like this is to put in lines of code to
write out to log files. You usually spot something unusual then and can
refine it or fix it.
Something like
if file('alerts.txt')
strtofile('My messages','mylogfile.log',.t.)
endif
You can then turn off the logging by removing the alerts.txt.
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR.
Tel:0161 831 3700
Fax:0161 831 3715
London Office:17-19 Foley Street, London W1W 6DW Tel:0207 299 7960
_______________________________________________
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/80f54570-ab11-95fd-c5c1-f28812703e9f@whisperingsmith.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.