Home All Groups Group Topic Archive Search About
Author
14 Apr 2005 4:32 PM
Jason Hunt
I'm hoping someone can help me out with using the Visual Studio IDE for
debugging.

I'm working on a Windows Forms application (it's an MDI if it matters), and
I'm trying to fix a bug in my program.  What's happening is
when the program is running, it runs into an exception error and switches
back to the Visio Studio screen.   The problem is that it's not
showing me the line of code which actually caused the exception.  Instead it
is showing the code for my startup form there is a green arrow
beside the "Public Class frmMain" line at the top of the code.  How do I
have VS automatically jump to the line which caused the exception?

I've figured out where the problem is happening, by putting some breaks in.
I have a break before the line which is causing the exception
(this line is in the code of a different form, frmParts.vb, not frmMain.vb)
When it hits the break, it switches back to VS and highlights the
line with the break in frmParts.  I press Step Into, it runs the line of
code, and then comes back to VS and highlights the next line in frmParts
(this is the line that's causing the exception).  When I press Step Into
again, it runs the code, and comes back to VS with the dailog "An
unhandled exception of type 'System.ArgumentOutOfRangeException' occurred in
system.windows.forms.dll"  That is fine, but now it's
highlighting the "Public Class frmMain" in frmMain.vb.  I want it to be
highlighting the line which caused the exception, not the Public
Class line of the parent form.

In case it matters, the build type is set to "Debugging", not "Release"

Is there a problem with the way I'm trying to do debugging here?  Please
keep in mind that I'm not asking for help with what's causing the
exception errors, I'm asking for help in the debugging process.

Any suggestions are appreicated.

Author
14 Apr 2005 5:36 PM
Charlie
You should put the block of code that is being called into a Try block and
trap the exception.

Try
....code
Catch ex as exception
messagebox.show ex as exception & controlchars.crlf & ex.stacktrace
End Try

At the end of stacktrace, the offending line number will be revealed.  You
can put a
breakpoint on that line.  When the breakpoint is tripped, you can highlight
sections of the line and get the return value using a mouse layover, or if a
single variable, just lay the mouse over it.

If the return value does not show up for a phrase, copy the phrase to the
Command Window and try using "? <<the phrase>>", Enter.

The Command Window is available under View | Other Windows  (rel 1.0)

Also, during debugging, one of the toolbars at the top of the IDE gives you
the Stack Frame.  You can follow the code by block backward from the
offending line to see where parameters are being passed to the block that
contains the offending line. 

In the Stack Frame, the lines containing "::" symbols are IL code, and
usually those are of little value to us mortals.  But the other lines can be
very useful in determining if you are passing parameters correctly.

www.charlesfarriersoftware.com

Show quoteHide quote
"Jason Hunt" wrote:

> I'm hoping someone can help me out with using the Visual Studio IDE for
> debugging.
>
> I'm working on a Windows Forms application (it's an MDI if it matters), and
> I'm trying to fix a bug in my program.  What's happening is
> when the program is running, it runs into an exception error and switches
> back to the Visio Studio screen.   The problem is that it's not
> showing me the line of code which actually caused the exception.  Instead it
> is showing the code for my startup form there is a green arrow
> beside the "Public Class frmMain" line at the top of the code.  How do I
> have VS automatically jump to the line which caused the exception?
>
> I've figured out where the problem is happening, by putting some breaks in.
> I have a break before the line which is causing the exception
> (this line is in the code of a different form, frmParts.vb, not frmMain.vb)
> When it hits the break, it switches back to VS and highlights the
> line with the break in frmParts.  I press Step Into, it runs the line of
> code, and then comes back to VS and highlights the next line in frmParts
> (this is the line that's causing the exception).  When I press Step Into
> again, it runs the code, and comes back to VS with the dailog "An
> unhandled exception of type 'System.ArgumentOutOfRangeException' occurred in
> system.windows.forms.dll"  That is fine, but now it's
> highlighting the "Public Class frmMain" in frmMain.vb.  I want it to be
> highlighting the line which caused the exception, not the Public
> Class line of the parent form.
>
> In case it matters, the build type is set to "Debugging", not "Release"
>
> Is there a problem with the way I'm trying to do debugging here?  Please
> keep in mind that I'm not asking for help with what's causing the
> exception errors, I'm asking for help in the debugging process.
>
> Any suggestions are appreicated.
>
>
>
Author
14 Apr 2005 5:40 PM
Jason Hunt
Maybe I should also mention that the debugger used to act the way I wanted
it to (highlight the line that caused the exception upon breaking), but then
for some reason it started doing what I have described (green arrow) - so I
have a feeling it's an option somewhere maybe?

I looked through the MSDN library, and all I've been able to figure out is
that the green arrow has something to do with the call stack.  I have no
clue what to do about it through.
Author
14 Apr 2005 8:23 PM
Charlie
The green arrow just means that the error is happening on a line of code in
the block being called by the line that the green arrow is pointing to.

You could put a breakpoint where the green arrow is, re-run the code, and
use F11 to get to the called block.  If you use Try blocks in all your
routines, and use the StackTrace property of the exception, you should be on
your way to resolving errors more quickly.

Show quoteHide quote
"Jason Hunt" wrote:

> Maybe I should also mention that the debugger used to act the way I wanted
> it to (highlight the line that caused the exception upon breaking), but then
> for some reason it started doing what I have described (green arrow) - so I
> have a feeling it's an option somewhere maybe?
>
> I looked through the MSDN library, and all I've been able to figure out is
> that the green arrow has something to do with the call stack.  I have no
> clue what to do about it through.
>
>
>
Author
14 Apr 2005 5:43 PM
Charlie
Correction from previous post:

old...

Catch ex as exception
messagebox.show ex as exception & controlchars.crlf & ex.stacktrace

new...

Catch ex as exception
messagebox.show(ex.message & controlchars.crlf & ex.stacktrace)


Show quoteHide quote
"Jason Hunt" wrote:

> I'm hoping someone can help me out with using the Visual Studio IDE for
> debugging.
>
> I'm working on a Windows Forms application (it's an MDI if it matters), and
> I'm trying to fix a bug in my program.  What's happening is
> when the program is running, it runs into an exception error and switches
> back to the Visio Studio screen.   The problem is that it's not
> showing me the line of code which actually caused the exception.  Instead it
> is showing the code for my startup form there is a green arrow
> beside the "Public Class frmMain" line at the top of the code.  How do I
> have VS automatically jump to the line which caused the exception?
>
> I've figured out where the problem is happening, by putting some breaks in.
> I have a break before the line which is causing the exception
> (this line is in the code of a different form, frmParts.vb, not frmMain.vb)
> When it hits the break, it switches back to VS and highlights the
> line with the break in frmParts.  I press Step Into, it runs the line of
> code, and then comes back to VS and highlights the next line in frmParts
> (this is the line that's causing the exception).  When I press Step Into
> again, it runs the code, and comes back to VS with the dailog "An
> unhandled exception of type 'System.ArgumentOutOfRangeException' occurred in
> system.windows.forms.dll"  That is fine, but now it's
> highlighting the "Public Class frmMain" in frmMain.vb.  I want it to be
> highlighting the line which caused the exception, not the Public
> Class line of the parent form.
>
> In case it matters, the build type is set to "Debugging", not "Release"
>
> Is there a problem with the way I'm trying to do debugging here?  Please
> keep in mind that I'm not asking for help with what's causing the
> exception errors, I'm asking for help in the debugging process.
>
> Any suggestions are appreicated.
>
>
>
Author
14 Apr 2005 6:42 PM
Oenone
Jason Hunt wrote:
> The problem is that it's not
> showing me the line of code which actually caused the exception.

Do you have the IDE set to break on exceptions?

Select Debug>Exceptions from the menu, and select the "Common Language
Runtime Exceptions" item in the list. Then in the "When the exception is
thrown" box, select "Break into the debugger."

This will cause the code to break immediately any exception occurs, allowing
you to see exactly where it happened.

--

(O) e n o n e
Author
15 Apr 2005 2:25 PM
Jason Hunt
Hi Guys,

Thanks for the assistance.  It turns out that what I described (green arrow
pointing to startup form instead of actual line of code) was only happening
when the exception was caused outside of the startup form's class.  I have a
"business objects" class which does all the underlying work, and then the
forms for all the UI stuff which open instances of the business class.  The
form was calling a function in the business class, and it there was a
missing bracket in an SQL query.

Charlies' suggestion of using Try/Catch narrowed it down.