We Keep Coding

Winforms application stops drawing but remains reactive to events

We have a C# .NET 3.5 UI client application that runs in a multiple monitor desktop environment (typically 4 screens) on Windows 7. Every so often, after running several of these applications, the screen stops redrawing.
Controls continue to be reactive to clicks or keypress and values can be updated programmatically, but the entire form is not redrawn to reflect any changes. For example buttons that are enabled/disabled based on state may be remain grayed out, but be reactive to clicks or vice versa. Buttons do not animate when clicked.
Workaround: minimizing and restoring the window appears to clear the problem. After this, the application begins to draw correctly.
The must frustrating aspect of this problem is that programmatically, everything appears to be running normally. No exceptions are caught in our logs. Nothing was visible in the system event logs. We have not found a way to detect this condition is happening yet.
Other miscellaneous aspects: logging uses log4net, server communication layer uses ZMQ
Update:
Calling form Invalidate() and Update() does not fix the problem.
When dragging the window between screens, it shows different values on each screen.
Minimize/restore still resolves the issue.

I can't be sure of anything without seeing the app and the code, but my best guess is someone calls .SuspendLayout() before a complicated update, and an exception (probably swallowed) prevents the code from ever reaching the corresponding .ResumeLayout(). To test this, try adding a button that calls .ResumeLayout() for the form.

It seems the solution is there:
1) http://blogs.msdn.com/b/alejacma/archive/2009/08/11/controls-won-t-get-resized-once-the-nesting-hierarchy-of-windows-exceeds-a-certain-depth-x64.aspx
2) http://support.microsoft.com/kb/2664641/en-us

Small flickering when showing a modal dialog in .NET

I'm experiencing a annoying issue in my .NET Windows Forms application.
I have a MainForm (A) and a progress form (B) that is shown modal when I start a long operation.
When the operation finishes, and B is closed, it seems that the window that is behind my application (is occurs usually with Skype) is brought to front during few milliseconds and, then my application is activated normally.
Is only a small flickering, but annoying. Here I write some tips that could help to find the solution:
I called showDialog without IWin32Window, but I added it without success result.
I closed B using Close(), then I tried Hide() and then Close() but did not help.
The code that executes the ShowDialog() is invoked from the UI thread, so it don't seem to be a threading issue.
Any clue would be appreciated. Thanks in advance.

I was experiencing these same symptoms and it was driving me crazy.
I finally discovered the problem was that i was calling this.Dispose() instead of this.Close() to close the modal window I'm not sure why I called this.Dispose() in the first place.
After switching methods, the problem went away.
I realize that this thread is old and this is not the cause of your problem, i am just trying to help anyone else who made the same mistake that I did.

Check if you DON'T call Hide or Close. The only way to avoid flickering is DialogResult.
Upd:
this.DialogResult = DialogResult.Ok
Check handlers OnFormClosing and etc. They might containt wrong method call.
The little trick is to set Owner explicitly
_dialog.Owner = this;
_dialog.ShowDialog();
People who are editing the post - _dialog.ShowDialog(this) works a bit different.
Look at owner = ((Control) owner).TopLevelControlInternal; in decompiled code
Edited by someone:
Or...
_dialog.ShowDialog(this);
These calls are identical according to MSDN

Do not call Close for modal window (it will not be disposed and memory leak is guaranteed)
Set this.DialogResult = DialogResult.OK
Call Dispose() from the parent, NEVER from the form you are closing
Remember of disposing all of your components holding by the form IContainer in Dispose(bool) (VS Designer implementation of Dispose(bool) is usually not enough not to have memory leaks)

In my case I was also facing the same issue in my VB.Net winform application but a bit different scenario.
I was having a user control which opens up a dialog using showdialog() say dialog1 and on filling some data it hides dialog1 and opens up dialog2 using showdialog() again.
In the process of hiding dialog1 and showing dialog2 flickering occurs and it shows the window at background for a moment.
After trying so many solutions and workarounds none work for me. I found one workaround myself which might help others.
To hide dialog1 I was using Me.Hide(), The solution is to change the opacity of form instead of calling Hide() method.
'Me.Hide()
Me.Opacity = 0
After this workaround the application works fine without any flickering issue.
PS: The above code lines are in VB.Net but enough for a .Net winform application developer to get the idea for fixing this issue.

Okay,
it sounds like
In the main window a user starts a long operation
You display a progress modal window
Operation completes you close the progress window
Your main window doesn't display immediately. Instead something behind it shows through for a second or less.
Your main window completes it's redraw operation and is 100% visible.
This happens more often when you have applications such as Skype running.
If that's the case there are many different possible causes. For example, your video drivers might have a bug in them causing delays in off screen compositing under certain conditions.
The system itself might even be experiencing a blocking CPU operation at the moment. This is something that could be caused by the time it takes your code to close the dialog and go back to the main form. You might look to see if there is anything else you are doing between the time the progress closes and you return UI control back to the user.
The system might simply be memory constrained and your operation causes a huge swap to disk. When the operation completes, windows might be notified that it needs to pull previously swapped memory from disk and shove it back into RAM, causing a delay.
I'd run the app with Nothing else loaded but task manager or resource monitor and see what happens. If the problem no longer occurs, then look into adding more RAM to your machine and/or ignore it.
If it's still occuring, and your memory usage leaves nearly nothing left then, again, add RAM or ignore.
If it's still occuring but memory usage is low, investigate your code to see what you are doing between the closing of the dialog and release of control of the main window back to the user.

You could try double buffering your form with this example:
Tends to eliminate flicker on screen updates.

Windows form not repainting

I am new to C# but I have been programming with VB6 for a long time. I have a very simple project that runs without any errors. There is one problem however and it has to do with the Windows itself. If I open up any Window (from any other program) and that window overlaps my application...the moment I close that "other window", my application's Window does not repaint the portion that was overlapped by the "other window".
The same thing happens whenever the Bubbles screensaver comes on for Windows Vista. When I jiggle the mouse to cancel the screen saver, guess what??? I have bubbles scattered all over my Window. In VB, we had a simple "Window.Refresh" and voila! In C# however, this does not work. I have scoured the forum(s) and there seems to be a mention of "refreshing a thread". I'm kind of confused at this point. Why can't things be simple??

You can call Form.Invalidate to invalidate the client area of the form. That will cause it to receive a paint message, and redraw itself.
This is similar to the VB6 Refresh method.
However, this should happen automatically. If your application is doing some processing in the UI thread, however, it will prevent it from processing its messages until the work is completed. If this is the case, you should consider using BackgroundWorker (or some other method) to push the work onto a background thread.

There is nothing special you should need to do to redraw the Form in C# (Form should redraw fine when you bring the window back to the top).
Do you have any third party controls in play? Control.Refresh() does exist in C#, should you should be able to call it from the Form itself (usually this.Refresh() in your Form's codebehind), or any Control which has children (like Panel).

Application not receiving event when clicked on taskbar

I have a .NET application (C#, WinForms) application running on Windows XP. If i minimize my application, and have several other windows minimized to the taskbar, and click on my application (in the taskbar) then often i see the taskbar "icon" blink but my application fails to "restore" its window. Any suggestions to what might cause this? Any hints on how to check if my application is not getting an event from the mouse-click.
UPDATE: Could anybody give an example of, how to output any incoming events to an application. Something that allows me to e.g. print the received events using Console.Writeline() to see, if my application gets an event when I click on the taskbar?

http://www.catch22.net/software/winspy-17
I venture to guess that your app will become in focus.

AFAIK this should not have anything to do with your application. Is there any other application running which always remains on top?

You dont handle maximising and minimising to and from the taskbar in your app. That is to say you dont have to. Windows deals with this and so this would appear to be in no way related to your app not handling an event, rather Windows doing something (or not doing something).

Animated gif on button stops after moving (redrawing) the form

I have an animated gif placed on the button. It's animating ok (most of the times :P) but when the windows is redrawn (repainted) the animation stops. I have tried to refresh the button (button.Refresh() ) while handling Paint event but it didn't solve the issue. \
Anyone knows how to fix this?

Perhaps I am mistaken, but I think the issue is that it stops animating not when the form is redrawn, but when the animated object is obscured by another window. This is intended behavior; the bug is that in Windows Vista and Windows 7, the display is composited, so even though the window was 'obscured' it was never truly obscured, and it will never receive paint messages when un-obscured which will kick the animation back in.
This bug appears to affect any ButtonBase-derived control with an animated object.
The issue is the Control.IsWindowObscured function. It will return true. You can see in the ButtonBase.cs file, at System.Windows.Forms.ButtonBase.OnFrameChanged, there is a line of code at the very end that says:
if (IsWindowObscured) {
StopAnimate();
return;
}
and therein lies the problem.
FYI, OnFrameChanged is called from the ImageAnimator thread. This is the callback that is specified in ImageAnimator.Animate(image, eventhandler). ButtonBase sets this up in the private void Animate(bool animate) function. The ImageAnimator thread polls every 50ms and checks to see if a new frame is necessary for any of the images it is monitoring; if so, it sets a flag to have the control invalidated and the new frame drawn.
Since this is inaccessible to us, I don't think there is much we can do about it. As a workaround, I implemented a timer in my form that invalidates the control every 500ms, so it will force it to restart if it had previously stopped. It is quite annoying that we can't override or even access it. I'm afraid the only solution is the hack above, or to create or use a control created by yourself or a third-party.
To clarify -- this is only a problem on Windows Vista or Windows 7 using desktop composition. The issue is that windows are never truly obscured, like they are when not using desktop composition. They are always buffered by the window manager. (There are special layered windows in windows 2000+, but ignore that for now). Previously, the parts of a window were not available if they were not on the screen or obscured by another window. When they came back into view, by changing focus or position etc, then the system will notify that area to repaint itself. However when using desktop composition, the repainting is never required, since the actual contents of the window are buffered elsewhere. This is why the window previews work in the taskbar, and Flip-3d, for example. The side effect is that code that expects to get a paint message when it is visible once again after being obscured will fail. The ButtonBase code expects to recieve a paint message once it comes back into view, which will start the animation again. And therefore, this optimization became a bug.
The issue should be reported in Microsoft Connect, though it is unlikely to be resolved.