Evil trick to render UI when stopped at a breakpoint.

Here's an EVIL trick to render your UI in a winforms app when you're stopped at a breakpoint.

When managed-debugging, when you hit a breakpoint, all the managed threads stop. With a winforms app, the UI thread is managed and so it stops too. However, that same UI thread that's pumping WM_Paint messages is also likely running  most of your application's code (via event handlers like OnButtonClick and things). Thus if you hit a breakpoint in your winforms app, it's likely on the UI thread in one of your messages, and thus blocking the UI thread from drawing.  (And note that no other thread can draw the UI).

Sometimes when debugging, you really need to your app draw something because your UI is effectively a complex Visualizer for essential data, and navigating the raw data is impractical.

So how do you get the UI thread to draw?
The answer is func-eval (aka function-evaluation, property-evaluation) a message pump! The message pump will then go dispatch WM_Paint messages and let the UI draw. (WARNING: this is evil)

Specifically, in the VS immediate window, try:
    ? System.Windows.Forms.MessageBox.Show("pump");

The funceval will hijack your thread from it's current to execute MessageBox.Show, and the message box will invoke a pump, which will let you UI thread redraw. And since it's a modal dialog, it prevents other disturbances besides redraw (such as you opening a menu). The end user effect will be that:
- your debuggee resumes
- you see a message box saying "pump"  (it doesn't matter what text you put here)
- your app is drawing in the background.
When you close the message box, your debuggee is right back where you left it. (hopefully....)

This is dangerous!!!
I emphasize that this is very very dangerous - only do it if you a) are Desperate, b) know what you're doing, and c) promise not to complain if it blows up.  Func-eval is dangerous enough. In this case, you introduce new reentrancy paths. For example, that message pump may go off and invoke other code that you didn't expect.  But in my case, it was a life-saver, so I'm passing on the tip.

In contrast to everything I just said here, if you're trying to play by the rules, you should check out Gregg's blog on Winforms and Funceval.

Comments

• Anonymous
  December 07, 2005
  Eval'ing a call to "Application.DoEvents" seems to have a similar effect, but with no need to dismiss a modal dialog.
  
  But perhaps there's more potentially dire consequences with that approach that I'm not seeing.
• Anonymous
  December 07, 2005
  The comment has been removed