Well, by jumping, I mean that when the IDE hits a line of code that causes
an exception to be thrown, (I know that because I can place a try block
around it which I did after it exhibited this stupid behavior), the next
line of code that gets executed is a line of code in an event handler for
one of the controls in my project. This event code is what would run when
the form is activated. So, to me this means that the form is getting send to
the front after the exception which causes the event code to activate. This
behavior continues whenever a line of code gets executed that causes an
exception to be thrown. What I would expect, however, is that the exception
would cause the IDE to either break at that line or cause the project to
crash due to an unhandled exception.
Perhaps is does need to be cleaned and rebuilt. I'll try that. I hope I made
sense there.
Steve
"Phill. W" <P.A.Ward@o-p-e-n-.-a-c-.-u-k> wrote in message
news:ce**********@yarrow.open.ac.uk...
"Steve Long" <St**********@NoSpam.com> wrote in message
news:Ov*************@tk2msftngp13.phx.gbl... when a line of code is executed that throws a nullreferenceexception
. . . the runtime just jumps to some other line of code (seemingly
unrelated to the line that caused the exception) instead of crashing
and throwing up an exception dialog.
"... the runtime jumps ..." - exactly what do you mean?
If you mean the Visual Studio IDE, make sure that you've [completely]
rebuilt the [dll] solution - it could be that the dbeuggin information is
out of step with the actual dll, so the IDE gets touch confused.
HTH,
Phill W.
