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

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

Sean
Wed Aug 01 10:02:09 CDT 2007

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

On aug. 1, 09:58, Sean Aitken <sean.ait...@gmail.com> wrote:
> 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

Sean
Wed Aug 01 10:29:18 CDT 2007

Found the root problem. Passing the form (this) as a delegate
parameter.
Now.. trying to understand why...

-s-

On aug. 1, 11:02, Sean Aitken <sean.ait...@gmail.com> wrote:
> 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
>
> On aug. 1, 09:58, Sean Aitken <sean.ait...@gmail.com> wrote:
>
> > 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

Jesse
Wed Aug 01 12:00:34 CDT 2007

* 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...

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


>
> -s-
>
> On aug. 1, 11:02, Sean Aitken <sean.ait...@gmail.com> wrote:
>> 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
>>
>> On aug. 1, 09:58, Sean Aitken <sean.ait...@gmail.com> wrote:
>>
>>> 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
>
>

Sean
Thu Aug 02 17:14:00 CDT 2007

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


On aug. 1, 13:00, Jesse Houwing <jesse.houw...@nospam-sogeti.nl>
wrote:
> * 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...
>
> 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
>
>
>
> > -s-
>
> > On aug. 1, 11:02, Sean Aitken <sean.ait...@gmail.com> wrote:
> >> 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
>
> >> On aug. 1, 09:58, Sean Aitken <sean.ait...@gmail.com> wrote:
>
> >>> 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