Thirty years ago when I got out of college and got a job selling computers (where I got my first exposure to Foxpro for DOS), I met an older in-house service technician ( he started out fixing typewriters and then migrated to computer repairs) who told me, "Computers would be a lot more fun if we could get rid of all the users."
Never forgot that comment or that guy. Didn't hurt that his name was Paul as well. Paul H. Tarver Tarver Program Consultants, Inc. Email: [email protected] -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Ken Dibble Sent: Tuesday, September 26, 2017 10:34 AM To: [email protected] Subject: Re: [NF]Debugging Pain Survey I am embarked upon such a project right now, cleaning up/refactoring/commenting a bunch of code from a recent, very fast-moving project now that user demand for changes has slowed down. Here's my list of most common issues: 1. Typos 2. Bad Variable References (really, just a subset of Typos) 3. Incorrect Data Types 4. Logic Errors 5. Unexpected User Actions There are two of these that I just can't seem to find a way around: A. User fat-fingers some bizarro combination of keys, causing a crash. B. User finds some way to input something even when the mouse cursor is an hourglass (okay, okay, spinning circle, or whatever nonsensical emoji is current in Windows 10, for all you modernistes) and when all the buttons are disabled. Some of this is VFP's notorious set of screen update/paint/event issues. You know, you have some routine or loop of code, in the midst of which a button is supposed to be disabled or a control made visible or invisible, but it doesn't actually happen until after the routine/loop is finished, no matter how many DOEVENTS, WAIT ... TIMEOUT, Paint() and/or Refresh() lines you put in. I have also discovered that the user can sometimes defeat hourglass/disabled control stuff by jumping to some other application during some time-consuming process, and then jumping back into my program before the process completes. The rest of those in the list aren't an issue for me. 6. Other: A. There is still, I think, some sort of really insidious corruption in my various project files that allows bad code to compile without throwing errors. This results in very rare instances of inexplicable crash errors. A missing or extra END... something perhaps, somewhere. I will probably never find it. B. I am still occasionally having "invalid subscript" errors on arrays even after conducting an exhaustive code search for array loop counter variables that were not declared LOCAL (after Ted's suggestion--Thanks Ted!--a while back I found a small handful and so these are occurring much more rarely than before). Has anybody ever constructed a utility that searches all of the methods/functions/procedures in a project specifically for variables that were not declared LOCAL in those routines? (I only have a handful of PUBLIC variables that are set when the program starts and are never deliberately changed, and I never use PRIVATE).* C. Connectivity Issues: I realize I can't fix broken hardware or cables through software, nor do I want to bog down my code with tests to ensure that everything is available across the network before every attempt to do something, but I wish I had a better handle on how to deal with some of these. Especially, lately, I would like to be able to "wake up" a dropped network share, since MS in their infinite wisdom decided it would be "helpful" to disconnect mapped drives that haven't been accessed within some mysterious amount of time (I'm aware of registry settings on both client and server side that are supposed to fix this; they simply DO_NOT_WORK). * I know, never use PUBLIC variables; put stuff in global objects or simply instantiate variables globally at program start up. It shouldn't be a problem as long as those variables are intended to be static. And I need stuff to be available before any objects are instanciated and after all of them are destroyed. 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/[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.
