Agree with your addition. I think I was more or less thinking of self-inflicted bugs initially.

Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Tuesday, September 26, 2017 9:39 AM To: profoxtech@leafe.com Subject: RE: [NF]Debugging Pain Survey

+ Bad product (Component Documentation) either not correct or just plain wrong. ... Currently struggling with C# Office Interop and finding conflicting Microsoft documentation. ... now my first port of call is sites such as StackOverflow and not the manufacturer...

-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: 26 September 2017 15:25 To: ProFox@leafe.com Subject: [NF]Debugging Pain Survey

Since this could technically apply to any programming language, I'll tag it as [NF], but Foxpro was the inspiration for the question.

This past weekend, I was working on a significant refactoring of an existing application and I found myself in that never-ending land of try and re-try until all of the dumb, crash causing bugs were out of the way and I could get on with working on logic issues and other more important thoughts. There are a lot of different "bugs" that get in the way of programming success many of which I experience on a regular basis. So, I thought it might be fun and interesting to try to find out what programmers think their biggest sources of bugs are.

Below is my short list of bug sources in no particular order. Rank them in the order of the pain they cause you from most to least:

Typos

Bad Variable References

Bad Object References

Logic Errors

Unexpected Data Variations

Incorrect Data Types

Local vs Public Variables

Cut n Paste Code

Unexpected User Actions

PS: if you can think of more sources of bug pain, please add them as required.

Paul H. Tarver Tarver Program Consultants, Inc.

Email: mailto:paul@tpcqpc.com paul@tpcqpc.com

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---

[excessive quoting removed by server]

The one that bites everyone:

The difference between what you see ..... and what you THINK you see!

Dave

-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: 26 September 2017 15:52 To: profox@leafe.com Subject: RE: [NF]Debugging Pain Survey

Agree with your addition. I think I was more or less thinking of self-inflicted bugs initially.

Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Tuesday, September 26, 2017 9:39 AM To: profoxtech@leafe.com Subject: RE: [NF]Debugging Pain Survey

+ Bad product (Component Documentation) either not correct or just plain wrong. ... Currently struggling with C# Office Interop and finding conflicting Microsoft documentation. ... now my first port of call is sites such as StackOverflow and not the manufacturer...

-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: 26 September 2017 15:25 To: ProFox@leafe.com Subject: [NF]Debugging Pain Survey

Since this could technically apply to any programming language, I'll tag it as [NF], but Foxpro was the inspiration for the question.

This past weekend, I was working on a significant refactoring of an existing application and I found myself in that never-ending land of try and re-try until all of the dumb, crash causing bugs were out of the way and I could get on with working on logic issues and other more important thoughts. There are a lot of different "bugs" that get in the way of programming success many of which I experience on a regular basis. So, I thought it might be fun and interesting to try to find out what programmers think their biggest sources of bugs are.

Below is my short list of bug sources in no particular order. Rank them in the order of the pain they cause you from most to least:

Typos

Bad Variable References

Bad Object References

Logic Errors

Unexpected Data Variations

Incorrect Data Types

Local vs Public Variables

Cut n Paste Code

Unexpected User Actions

PS: if you can think of more sources of bug pain, please add them as required.

Paul H. Tarver Tarver Program Consultants, Inc.

Email: mailto:paul@tpcqpc.com paul@tpcqpc.com

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---

[excessive quoting removed by server]

+1 :-)

John Weller 01380 723235 079763 93631 Sent from my iPad

On 26 Sep 2017, at 15:59, Dave Crozier DaveC@Flexipol.co.uk wrote:

The one that bites everyone:

The difference between what you see ..... and what you THINK you see!

How true!

Laurie

On 28 September 2017 at 01:38, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:

On 2017-09-26 10:59, Dave Crozier wrote:

...

The one that bites everyone:

The difference between what you see ..... and what you THINK you see!

"Well it works fine on my machine."

[excessive quoting removed by server]

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: paul@tpcqpc.com

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken Dibble Sent: Tuesday, September 26, 2017 10:34 AM To: profoxtech@leafe.com 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]