2

In any .NET 2.0 Winforms application, if you run the code in Debug Mode, and you either hit a breakpoint or otherwise Step Into the code line by line, and you want to see the GUI of the application being debugged, then .NET does not draw the application screen.

For example, I have an application which writes some messages to a TextBox on a Form. When I debug the code step by step, or when a breakpoint is hit, I want to see what all messages are logged in the TextBox, but if I press Alt-Tab to switch from VS2005 window to the WinForms application window, all I see is white color. The form is not redrawn, until you press F5 in the debug mode in VS2005.

What is the reason for this, and is there a way to overcome this, without introducing any threads in the code?

p.s.w.g
  • 146,324
  • 30
  • 291
  • 331
AllSolutions
  • 1,176
  • 5
  • 19
  • 40
  • When you have stepped into your process, all threads are suspended, so no messages are being pumped. You are better off using `Debug.WriteLine` to write to the debug output and watch what appears there without having to break. – vcsjones Mar 06 '13 at 18:25
  • 1
    Sure, the UI thread was frozen by the debugger. The window isn't going to update until you resume running. Later, when the UI thread goes idle again and gets the paint request. This is by design. – Hans Passant Mar 06 '13 at 18:27
  • @vcsjones: Yes, but isn't it the case that anything not going through the message pump, such as calls to OnPaint(), would happen synchronously in the debugger as you stepped over them? – Pieter Geerkens Mar 06 '13 at 18:29
  • I suppose it all depends on whether what you're trying to debug is a UI rendering issue. – Stewart Feb 07 '20 at 18:11

3 Answers3

3

What is the reason for this

While you're debugging, you're effectively blocking the UI thread - you're manually stepping through its execution flow. The UI thread can't draw the UI while you're stopping it from executing.

and is there a way to overcome this

You could try calling Application.DoEvents() manually, but I'd generally recommend against it.

It would be better to just wait until you got to the end of the method and let the UI redraw itself normally. If your method is very long (in terms of time) then bear in mind that when not debugging, the UI still wouldn't be able to update itself while that method is executing. This may cause you to change your design (it's hard to tell just from the information we've got at the moment).

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • How could any thread call `Application.DoEvents()` if it's suspended? Do you mean from the immediate window? – vcsjones Mar 06 '13 at 18:28
0

The reason for this is because you can only have one UI thread, and when you enter your method that updates that code that code begins blocking the UI thread. It will not update until your method exits.

Here is a good SO on message pumps, which are what drive the UI updates

You should be able to use Add Watch/Quick Watch to look at any values at the time of debugging. This sounds like what you are really looking for, anyway.

Community
  • 1
  • 1
Justin Pihony
  • 66,056
  • 18
  • 147
  • 180
0

Like everyone else has said in answers and comments, the UI thread is blocked so it cannot be redrawn.

However, if all you want to do is see the GUI, and not interact with it, and you are running Windows 7/8 (which sounds unlikely since you're using VS2005) and haven't disabled aero peek, you can mouse over your application in the task bar and Windows will show the preview thumbnail. When you mouse over the thumbnail, you can "peek" at the application even when the breakpoint is blocking the UI thread.

sparky68967
  • 637
  • 1
  • 5
  • 8