How can I force VB6 to enter the debugger from the execution of a program without a break point?

Question

I'm trying to watch the execution of a VB6 app and I'm running into an issue because once I enter the debugger and then hit Continue, it no longer lets me step through the code until I hit another break point. I want to be able to execute a program without stepping through something until I hit a point where I want to watch it execute. Ideally this would be something to the effect of holding a key down while I pressed a button to 'step into' that function.

Thanks in advance!

[EDIT]: I'm aware that I can use break points to stop the execution. To be more clear, the problem is that I don't know where the execution is going to, so I can't set the break point there (because I don't know where there is). That's why I essentially want to be able to say, 'after this next thing that I do, break, no matter what'. It sounds like this functionality does not exist, but I'm still keeping my fingers crossed.

Answer 1

You can press the F8 key to step through the code line by line. Alternatively, you can press SHIFT-F8 to step through line by line.

F8 will step you in to a function, where SHIFT-F8 will step you over the function. If you click on the DEBUG menu in the VB IDE, you will see other options too.

EDIT:

You can also put a permanent break point in your code by using:

Debug.Assert False

By doing it this way, the 'breakpoint' is saved in your code. When you compile the app, debug code is ignored.

Answer 2

There is a Stop statement available for use in VB6 that will drop to the debugger when the statement is executed from code running through the IDE. (Just be sure to remove the all of the Stop statements from the code when compiling a release build.)

Answer 3

While the code is running, press ctrl+break (or the 'VCR pause' button in the IDE) then press F8 (or choose 'Step Into'from the Debug menu in the IDE) to continue running the app. The next action will cause execution to break.

Note that the which causes the break will not always be the one you hoped it would be. Particularly annoying is the _MouseOver event which prevents you from doing a mouse down or a timer firing quckier than you can perform your action. Some breaks may even be fatal as regards running your app e.g. where Windows messages have been hooked (subclassing). Also consider there may not be an event handler in code (yet) for your action where it can break. But usually this technique identifies where you should be setting your breakpoint.

Answer 4

There are several techniques you can use.

These two have been mentioned

Using F8 and Shift-F8 to step through the program

Adding Stops (and later removing)

Others

Use a global variable to create a collection. Use it as a stack and have the subroutines you are interested in push and and pop strings. Conversely don't pop anything and you will get a trace.

Use Watches to monitor and break at selection conditions. You can setup just about any condition to break.

Make a Global String and have your procedures set when you enter them. Monitor it through a Watch.

Use Debug.Print in your code. Also Unlike Stop you can leave these in without effecting the production code.

Use the File System Object to create a text file to act as a log.

Sometimes problem only occurs in the Complied version then you need to use MsgBox or log to a text file. MsgBox can alter the behavior of complex user interactions with forms.

These are all techniques I used in debugging an application. If I had to monitor an application I would use Debug.Print. If that doesn't do the trick compile then log to a text file.

If you have something really complex going on then I recommend moving all your code out of the events into classes implementing a Command Pattern. Your commands classes should interact with the form through and interface.

In the Execute method of the command classes you will something like

<save the current state>
<Do your original code>
<save the modified state>
<push the command onto a stack>

What will happen is that you wind up with a list of all the commands you have executed (even things like mouseover) with the state they encountered and the modified state. You can then examine each object in turn to see what is happening. This is nearly the equivalent of creating Undo/Redo

Note however things like MouseOver can push a lot of classes on the command stack so you will have to structure your tests carefully or be overloaded with information. Remember you can always skip pushing the command onto the stack.

The downside of using commands is that you gone beyond debugging into redesigning. You will to decide whether the problem is worth doing this.

Answer 5

Hi, I have a VB6.0 programe to debug. I when i put Break point at a perticulare line in the code the execution don't stop. Can any one please suggest me on this.

Thanks Amit