1

I have some C# code writing progress messages to a Visual Studio 2010 EnvDTE.OutputWindowPane. The code is invoked from a Visual Studio menu (it's in a VSPackage).

The problem is that the output window is not repainted until all processing invoked by the menu pick is complete, so the output appears all at once rather than when each line is added. I suspect that this is related to all processing being performed on the main thread, so the Visual Studio UI can't repaint.

Is there a way to "pump messages" in Visual Studio to update the UI -- like Application.DoEvents()? The VSPackage also inserts some items in the project and that seems to happen "on the fly" -- it's only the output window that appears to lag behind.

I spelunked through the various DTE objects without finding any candidates for this functionality.

UweBaemayr
  • 1,861
  • 1
  • 18
  • 21
  • It sounds like the right fix is to just not do processing on the UI thread. – perelman Feb 12 '12 at 09:37
  • Yep, the plan is to try to move the processing to a worker thread, but it takes a significant amount of time and I'm concerned about how thread-safe some of the VS interfaces are or if there is thread affinity. Pumping messages at a known safe point seems less risky. – UweBaemayr Feb 13 '12 at 16:04
  • I am confused by what your problem is. Any UI changes should happen on the UI thread. You can ensure that by remembering `dispatcher = System.Windows.Threading.Dispatcher.CurrentDispatcher` in code on the UI thread and then later using `dispatcher` to execute any UI changes from another thread (perhaps with some extra fanciness if you want to guarantee your messages appear in the order they were sent). – perelman Feb 13 '12 at 16:17

2 Answers2

1

Sorry for the silence -- I was just reminded of this question and thought I'd answer it myself.

I was able to largely solve the problem by creating a progress bar window that appears while the main Visual Studio thread is off running my code and not updating the UI. The progress bar (IVsThreadedWaitDialog2) is very poorly documented, but it appears to run on a worker thread and puts Visual Studio into a modal state while active. So that, at least, keeps Visual Studio from looking like it's hung during during processing.

The progress bar window is the same one that appears when Visual Studio is loading a large solution and has the option of a Cancel button.

Unfortunately, the progress bar dialog has several bugs (reported to Microsoft), the most significant of which is that it often appears behind the Visual Studio window -- truly annoying. That's kind of a show-stopper, so whenever the progress bar is updated, I use a variation of the code here to locate the progress window by its title and bring it to the top of the Visual Studio window stack.

Moving the processing to a worker thread didn't work very well, as it executes shared code that manipulates text in the Visual Studio editor, and the results of those manipulations were erratic (sometimes it would work, sometimes an inscrutable COM error was returned, which seemed to be timing-dependent).

I also did finally find a message pump in Visual Studio -- the shell contains a class called CommonMessagePump. Again, it is very poorly documented and I could never get it working quite right based on the information that was available. In any case the progress dialog has solved my problem.

UweBaemayr
  • 1,861
  • 1
  • 18
  • 21
1

In my case, I was able to call System.Windows.Forms.Application.DoEvents() immediately after writing to the output window and that solved the problem.

Asim Shah
  • 11
  • 1