Step on when an expresion is true 2

[meny21]

Hi guys!

Just to know, is there any way I can run a program and then this stop to start debugin when an expresion is true??

For example reading a lot or records but I only would like to review (step on) when my Variable containg a value? (for example MYVAR = "AABB")

This can make me debugging so fast and better.....

Thanks for any help!

MR

 

[strongm]

In the IDE have a look at Debug/Add Watch...

 

[HughLerwill]

Try;

If myval = "hello" then Stop

Don't forget to rem it before you compile!

regards Hugh

 

[tsh73]

I did not used Watch for that, sure will have a try...
meny2, this is definitely the way.

But I did it this (deprecated) way:
added condition to check
inside IF do something meaningless (say "a=a")
and set a breakpoint to that meaningless code.
but now I see this is a QBasic remnants )

 

[meny21]

Hi Guys,

I already try in debug with this expression :

If myval = "hello" then Stop

But it tells me that it is invalid.... Thanks any way!!

tsh73 your option is so good that is what I need to improve my debbuging, sometimes things are more easy than we think ;O)

MR

 

[strongm]

???

 

[PatrickIRL]

Won't Debug.Assert <condition> do this?

Patrick

 

[HughLerwill]

Private Sub Form_Load()

Dim myval As String

myval = "hello"

If myval = "hello" Then Stop

'other code...............

End Sub

Does Work!

 

[BobRodes]

I'll bet meny just put myval in there without declaring it.

 

[HughLerwill]

Thanks for that Bob.

regards Hugh,

 

[BobRodes]

This is one of the things that Add watch can do.

Simply add a watch, enter an expression, and select break when the value is true. For example, let's say you're iterating through a recordset, and when you're done, a variable x equals 49 when it was supposed to equal 32. Instead of stepping through all the records in the recordset to find out when you're adding the number, you can add a watch, set its value to x = 49, and select break when value is true. You can then evalute the precise iteration of the recordset that's causing the trouble.

The other methods, using the stop statement or debug.assert, also work, but they involve lines of code. Some would assert that not having lines of code is preferable.

Bob

 

[gmmastros]

Bob,

Correct me if I am wrong, please.

When adding a 'watch', you can do as Bob suggests. However, if you close the VB IDE, and then open it again, the watch information is lost.

The alternative method would be to add a line of code...

debug.assert X <> 49

When x <> 49, the code will continue to execute. When it does = 49, then the app will stop running and you will be thrown back in to the IDE.

The difference is that debug.assert is saved with the source code, so when you open VB again, that line is still in there. When you compile the code, the debug.assert line is NOT included in the compiled version (same thing is true of debug.print).

This is why I use debug.assert. It's a minor difference, but one that you should be aware of because it can prove handy at times. For example... suppose you have a hard to track down bug (because it is data related and therefore harder to find). You can add a debug.assert line and then continue developing/testing other parts of the application. At some point, you may stumble upon the magical combination of data that is causing the problem giving you an oppurtunity to fix the problem.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[BobRodes]

Yes, all quite right George, and it's why I DON'T use Debug.Assert or Debug.Print. They get in the way.

Well, I don't use them unless I use them in the context of conditional compiling, thus:

#const IsDebug as boolean = True
'..all kinds of other code...
#If IsDebug Then
   '...Debug Asserts, Debug.Prints, log files, whatevers
#End If
'...all kinds of other code...

George is quite correct that the Debug object's methods don't compile, but in this way, NONE of the code in the #if block will compile if the #const IsDebug is set to false. Not only that, none of the debug methods will execute, even when you're running from the IDE. If you're ever at the point where you have "debug window clutter", as I can do when I use the Debug.print and Debug.assert this can be useful.

However, it's rare that I need to go to this level of trouble, personally. I'm a breakpoints and watches kind of guy.

Bob