Hi

I'm not sure this is the proper place but I couldn't find a dedicated group 
for visual studio so here goes:

I used to write responsive GUIs by creating threads to process long running 
operations, give feedback via event handler which ends up in the GUI 
domain.. e.g like this.

object sharedState;
OperationHandler handler = new OperationHandler();
handler.Feedback += new FeedbackHandler(handler_feedback);
new Thread(new ThreadStart(handler.run)).Start();

public handlerFeedback(object feedbackState)
{
    this.sharedState = feedbackState;
    this.Invoke(new EventHandler(myEventHandler));
}

public void myEventHandler(object state, EventArgs e)
{
    // do some processing in the GUI thread
}

where handler.run looks something like

void run()
{
    while(running)
    {
         // do something
        if (Feedback != null)
            Feedback(myObject);
    }
}

So far so good.. I've never had much of a problem debugging such code, but 
there are more elegant ways of handling things.

So I switched to using the ThreadPool instead of creating my own threads. So 
now instead of using

new Thread(new ThreadStart(handler.run)).Start();

to start the work, I use

ThreadPool.QueueUserWorkItem(handler.run, null);

The next step was swapping out the EventHandler and using an anonymous 
delegate:

So

public handlerFeedback(object feedbackState)
{
    this.sharedState = feedbackState;
    this.Invoke(new EventHandler(myEventHandler));
}

becomes

public handlerFeedback(object feedbackState)
{
    this.BeginInvoke((MethodInvoker)delegate()
    {
        // do some processing in the GUI thread
    });
    this.Invoke(new EventHandler(myEventHandler));
}

And tha's where I started getting problems. As long as I run the code 
without any breakpoints, there's no problem, But suppose I set a breakpoint 
within the anonymous method inside handlerFeedback.. then the method is hit, 
I press F10 and Visual Studio just sits there doing nothing. After a while I 
get the popup in the taskbar telling me VS is busy and if this happens often 
to contact Microsoft. The thing is.. it happens way too often, and every 
second or third time, pressing F10 will never return.. the app is still 
accessible and interestingly enough, Visual Studio also still reacts, but 
debugging just doesn't continue.

On top of making those changes, if I have the contents of handler.run in the 
GUI class and inside and do something like:

void run()
{
    while(running)
    {
         // do something
        this.BeginInvoke((MethodInvoker)delegate()
        {
             // processing in the gui thread
         });
    }
}

I have the same issue.

Also, I've been using the

void someAsynchronousMethod(object state)
{
    MyDelegate del = new MyDelegate(handler.run);
    IAsyncResult ar = delegate.BeginInvoke(callback, state);
}

template quite a bit recently, then send back the result via an event to the 
GUI class, and join the GUI thread via the

 this.BeginInvoke((MethodInvoker)delegate()
        {
             // processing in the gui thread
         });

logic - and that alone doesn't cause any problem so I think it's the 
combination of the ThreadPool along with the use of anymous methods to join 
the GUI thread that causes these locks.


Now I'm wondering.. am I doing something fundamentally wrong or does Visual 
Studio just have major debugging issues in such a scenario and I should 
either go back to doing things the more cumbersome way if I want to debug my 
code?

Regards
Stephan

Stephan,

    This is expected behavior when you break in the debugger.  ALL threads 
stop processing when you hit a breakpoint, not just the one that is 
processing the code you have set the breakpoint on.

-- 
          - Nicholas Paldino [.NET/C# MVP]
          - mvp@spam.guard.caspershouse.com

"Stephan Steiner"  wrote in message 
news:%23JlIdOY5HHA.5740@TK2MSFTNGP04.phx.gbl...

> Hi
>
> I'm not sure this is the proper place but I couldn't find a dedicated 
> group for visual studio so here goes:
>
> I used to write responsive GUIs by creating threads to process long 
> running operations, give feedback via event handler which ends up in the 
> GUI domain.. e.g like this.
>
> object sharedState;
> OperationHandler handler = new OperationHandler();
> handler.Feedback += new FeedbackHandler(handler_feedback);
> new Thread(new ThreadStart(handler.run)).Start();
>
> public handlerFeedback(object feedbackState)
> {
>    this.sharedState = feedbackState;
>    this.Invoke(new EventHandler(myEventHandler));
> }
>
> public void myEventHandler(object state, EventArgs e)
> {
>    // do some processing in the GUI thread
> }
>
> where handler.run looks something like
>
> void run()
> {
>    while(running)
>    {
>         // do something
>        if (Feedback != null)
>            Feedback(myObject);
>    }
> }
>
> So far so good.. I've never had much of a problem debugging such code, but 
> there are more elegant ways of handling things.
>
> So I switched to using the ThreadPool instead of creating my own threads. 
> So now instead of using
>
> new Thread(new ThreadStart(handler.run)).Start();
>
> to start the work, I use
>
> ThreadPool.QueueUserWorkItem(handler.run, null);
>
> The next step was swapping out the EventHandler and using an anonymous 
> delegate:
>
> So
>
> public handlerFeedback(object feedbackState)
> {
>    this.sharedState = feedbackState;
>    this.Invoke(new EventHandler(myEventHandler));
> }
>
> becomes
>
> public handlerFeedback(object feedbackState)
> {
>    this.BeginInvoke((MethodInvoker)delegate()
>    {
>        // do some processing in the GUI thread
>    });
>    this.Invoke(new EventHandler(myEventHandler));
> }
>
> And tha's where I started getting problems. As long as I run the code 
> without any breakpoints, there's no problem, But suppose I set a 
> breakpoint within the anonymous method inside handlerFeedback.. then the 
> method is hit, I press F10 and Visual Studio just sits there doing 
> nothing. After a while I get the popup in the taskbar telling me VS is 
> busy and if this happens often to contact Microsoft. The thing is.. it 
> happens way too often, and every second or third time, pressing F10 will 
> never return.. the app is still accessible and interestingly enough, 
> Visual Studio also still reacts, but debugging just doesn't continue.
>
> On top of making those changes, if I have the contents of handler.run in 
> the GUI class and inside and do something like:
>
> void run()
> {
>    while(running)
>    {
>         // do something
>        this.BeginInvoke((MethodInvoker)delegate()
>        {
>             // processing in the gui thread
>         });
>    }
> }
>
> I have the same issue.
>
> Also, I've been using the
>
> void someAsynchronousMethod(object state)
> {
>    MyDelegate del = new MyDelegate(handler.run);
>    IAsyncResult ar = delegate.BeginInvoke(callback, state);
> }
>
> template quite a bit recently, then send back the result via an event to 
> the GUI class, and join the GUI thread via the
>
> this.BeginInvoke((MethodInvoker)delegate()
>        {
>             // processing in the gui thread
>         });
>
> logic - and that alone doesn't cause any problem so I think it's the 
> combination of the ThreadPool along with the use of anymous methods to 
> join the GUI thread that causes these locks.
>
>
> Now I'm wondering.. am I doing something fundamentally wrong or does 
> Visual Studio just have major debugging issues in such a scenario and I 
> should either go back to doing things the more cumbersome way if I want to 
> debug my code?
>
> Regards
> Stephan
>