Debugging - stop on variable change?

[Gary Beene]

When I'm running the Debugger, I'd like for my program to stop when a specific variable changes its value.

I seem to recall that VB6 had such a feature, but I'm not seeing it in PowerBASIC.

Is there such a feature and I'm must not finding it?

A variable watch isn't much good because I don't know where to put the breakpoint, and there are at least 25 places where the change could happen. Push comes to shove, I'll just add a breakpoint at each one, but I was hoping for a less cumbersome approach.

A trace tells me where I've been, but not which of those locations resulted in a value change of the variable.

Suggestion?

[Michael Mattias]

Huh?

Since a variable can only change value in a statement you write, you put a break point point at such statements.

>and there are at least 25 places where the change could happen

Self-documenting problem?

[Chuck de Young]

Gary,

If you change the variable to a property you can test in the property code for the change you are interested in.

Chuck

[Michael Mattias]

Old:

  X = 12
....
  X = 14 
....
 X =  62

new:

 
#TOOLS ON 

  ...
    TRACE NEW  filename
....
    TRACE ON 
   
FUNCTION SetX (value) AS x'sdatatype
      TRACE PRINT USING$("procedure calling SetX to value # is &", value, CallStk$(2))  
      FUNCTION = value
END FUNCTION
....

  X = Setx (12)
....
  X = SetX(14) 
....
  X =  SetX(62)

Worth a shot methinks...

[Tom Hanlin]

Sounds like a fine idea for a debugging feature. I'll make sure it's on the list.

[Gary Beene]

Well of course I put code in to do it, but there might be 30+ lines where the variable changes. And then I have to take the code out too ... and I have to do it over again the next time, or for another variable.

I want a variable watch kind of thing, where I identify any (or several) variables as part of a debug session. The program then stops when a variable changes (or takes on a value outside a specified range).

That would be very convenient.

Thanks Tom. Until it's an IDE option, then I guess I'll do it the manual way as the other posters suggest.

... and wait, then when the program stops I want the complete call stack to pop up in a list - where I can select the sub/function to jump to in the stack.

That also would be very convenient.

[Michael Mattias]

And then I have to take the code out too ... and I have to do it over again the next time, or for another variable.

Conditional Compilation!!!!

(#IF ...#ELSE ... #ENDIF)

(I'd bet dollars to donuts there is some wag around here always preaching that one should include, "How am I going to test and debug this?" in the list of questions to be answered BEFORE writing that first line of code......)

[Tiziano Magni]

Conditional Compilation!!!!

(#IF ...#ELSE ... #ENDIF)

(I'd bet dollars to donuts there is some wag around here always preaching that one should include, "How am I going to test and debug this?" in the list of questions to be answered BEFORE writing that first line of code......)

Yes! But...
Why insert one hundred statements if a single line in the debug window can do the works?

IT IS a fine idea for a debugging feature.

[Michael Mattias]

Why insert one hundred statements if a single line in the debug window can do the works?

Because you can insert the 100 statements today.

MCM

[Tiziano Magni]

Because you can insert the 100 statements today.

MCM

Today, to debugging an application, I insert one hundred statements, tomorrow we may add a simple tick into an option box on the variable line in the variable watcher window of the debugging session...
Perhaps tomorrow some (all) of us might be much happier

[Rodney Hicks]

I want a variable watch kind of thing, where I identify any (or several) variables as part of a debug session. The program then stops when a variable changes (or takes on a value outside a specified range).

This shows why Michael's approach makes the most sense.

What is the variable doing in the program if it isn't going to change?
Variables are expected to change, that's why they are called variables.

Therefore you want to know when it changes when it isn't supposed to or if it changes beyond expected (range, value, etc.).

But you wrote it in the first place!? So if you're looking for a variable that is changing when it isn't supposed to you are likely to miss it even with this feature because you'll be setting the wrong parameter.

And if you set a range for the variable, and the variable is in error but still within the range, what then?? It seems that it would have to be set for the exact value(not a range) at every point the debugger is going to encounter the variable.
Michael's idea sounds a lot more efficient to me. Copy/Paste is a wonderful editing feature.

[Joseph Cote]

My vote is for changing the debugger.

Even if there's only ONE place where a variable gets changed I'd like to be able to break on change. Specific example: processing a long file, want to run the first few records manually, then let it run until a key value changes. Watch it process a few records then skip to the next control break.

Again, if you don't want to use it, don't use it. One size does not fit all.

[Michael Mattias]

Specific example: processing a long file, want to run the first few records manually, then let it run until a key value changes

???

I assume you are 'doing something' on a change of key. Add breakpoint.

Win32: Find Differences in WIN32API.INC and other text files April 21, 2000 (This is actually a generic 'merge-purge' application).

Count unique keys and occurrences thereof in sequential file (This is actually just what it sounds like).

MCM

[Barry Marks]

My guess is that if this feature is added all the naysayers in this thread will use it gleefully if they use debuggers at all.

The PB debugger is easily the best of any of the basics I've used in Windows, and I've tried several of them, but it doesn't compare very well to the debugger in Visual C, for example. There's lots of room for new features before it begins to seem bloated and having a variable changed breakpoint is a useful one.

Barry

[Jeff Blakeney]

Breaking when a variable or memory location becomes a certain value is a pretty standard debugger feature as far as I know. I've had that capability on my Apple IIgs for 15 to 20 years now. One really nice use for it is if you are having problems in a loop with lots of iterations and you notice that the output is going wonky starting at iteration 1000, instead of putting a break point at the top of the loop and hitting F5 999 times so that you can start stepping through the code, it would be nicer to just tell the debugger to break when the loop counter gets to 999 and hit F5 once.

If the debugger supported the ability to break whenever a variable is changed, regardless of what value it is changed to, it could help track down bugs where you might have used the wrong variable in part of your code that you didn't intend. This kind of bug can be very hard to find.