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