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" <[email protected]> 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" <[email protected]> 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: [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/[email protected] ** 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.
