Debugging method called from BeginInvoke(...) - Locks debugger, aborts thread

  • Thread starter Thread starter Sean Aitken
  • Start date Start date
S

Sean Aitken

Good Morning,

I am having an interesting problem. I am calling a method on a form
asynchronously through a delegate. In this case a loop to update a
progress bar:

private void UpdateUILoop()
{
for (int i = 0; i < 100; i++)
{
Thread.Sleep(3000 / 100);
this.Invoke(this.setProgDel, i);
}
}

(setProgDel simply sets the value of the progress bar)

Using BeginInvoke from a delegate seems to run through the Remoting
namespace (?).. but the wost of it is the inability to debug the
method invoked through BeginInvoke. When a breakpoint is set inside
the method, the IDE pauses (usually), then once the breakpoint is hit
and a continue is attempted, the thread is dead!

Has anyone seen this or knows why this is happening? I'm about to
refactor the solution so that BeginInvoke is not used, but I'd still
like to understand whats going on.

Best regards,
-Sean
 
For what it's worth, I just replaced the BeginInvoke on the delegate
with a custom thread and the problem still exists. The delegate is
still being called though...

any ideas?
-Sean
 
Found the root problem. Passing the form (this) as a delegate
parameter.
Now.. trying to understand why...

-s-
 
* Sean Aitken wrote, On 1-8-2007 17:29:
Found the root problem. Passing the form (this) as a delegate
parameter.
Now.. trying to understand why...
Click to expand...

My guess is that the this you're passing is shown in the Locals window.
which means that due to the fact that Visual Studio will try to show all
the values probably causes a deadlock due to the fact that the Invoke
call will also wait for the UI thread to become available.

Jesse
 
Ahh! I shoulda known! I saw this issue before, but manifested
differently.
Applying the Invoke(..) pattern to the ToString method on the form
prevents the dying thread. Not sure of the pause still. Overriding
TOString to return null works (or anything in a thread safe manner)!
Using the DebuggerDisplay attribute on the FOrm class also works, and
is probably the best solution!

Great find!

Well.. one problem solved. Still curious why there is a delay when I
use the this.Invoke(...).

Cheers!
-SEan
 
Hello Sean,
Ahh! I shoulda known! I saw this issue before, but manifested
differently.
Applying the Invoke(..) pattern to the ToString method on the form
prevents the dying thread. Not sure of the pause still. Overriding
TOString to return null works (or anything in a thread safe manner)!
Using the DebuggerDisplay attribute on the FOrm class also works, and
is probably the best solution!
Great find!
Click to expand...

I've been bitten by the Locals window before. It seemed the only logical
cause.
Well.. one problem solved. Still curious why there is a delay when I
use the this.Invoke(...).
Click to expand...

Can't help you there. It can be that the Ui thread is just busy doing something
else... Could be anything ;)

Jesse
 
Back
Top