WPF refresh after message box closed in vb.net

Question

I have two message boxes one after another. Dim msgResult as MessageBoxResult msgResult = MessageBox.Show("Message", "Title", MessageBoxButton.YesNo, MessageBoxImage.Question)

if mesgResult = MessageBoxresult.Yes Then 'some code..... MessageBox.Show("Another message", "Title", MessageBoxButton.OK, MessageBoxImage.Error)

End if

When the second message box gets closed the user remains on the same window, and the part of the title bar from the message box is still visible just above the windows text box. It seems that window did not get refreshed. How to handle this? Thank you.

Answer 1

This normally does not occur in a pure WPF applications. Situations I've seen where it does occur are:

1. Your UI thread is executing some long-running code and not processing messages
2. There is a bug in the video drivers
3. Window transparency is in use, that portion of the window is transparent, and a non-WPF application is responsible for painting it
4. You are integrating WPF with non-WPF technologies such as GDI (eg MFC), GDI+ (eg WinForms) or DirectX, and the area having trouble painting should be painted by the other technology. This includes the Frame and MediaPlayer controls which use non-WPF technologies under the hood.

The solutions vary:

• In case 1 and usually in case 4 the problem is often obvious and the solution is usually to fix your threading issues. If the threading problem is not obvious, breaking in the debugger as suggested by Hans Passant may reveal a long-running operation you weren't aware of, such as a database access.
• In case 2 you can diagnose it by temporarily switching to software rendering and fix it by updating your video drivers.
• In case 3 there is nothing you can do if the other app won't repaint, but users should recognize it is not an issue with your software.
• In case 4 if the threading issue is not obvious it is usually helpful to isolate the non-WPF code and see what message processing threads are active.

Note that executing long-running operations on the UI thread is generally a bad idea and if you need to run such operations your app should be multithreaded. However if your app is quick-and-dirty or you are otherwise ok with completely locking up the UI you can fix just the painting issue by making sure the Dispatcher queue is fully flushed before beginning your long-running operation. This is done by running an empty Dispatcher invocation at low priority, causing all higher-priority operations to execute first. For example:

Dispatcher.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() => {}));