Hi all,

We have a windows forms application with different controls used
inside, each control has several input items such as textboxes and some
treeviews.. etc.

We have been trying to eliminate flickering issues when loading
different controls or switching to different views with no luck, and
have been trying different suggested methods to get rid of the
flickering such as:
- this.SetStyle(ControlStyles.OptimizedDoubleBuffer, true);
- this.SetStyle(ControlStyles.AllPaintingInWmPaint, true);
- SuspendItemsLayout();
- ResumeItemsLayout();

Unfortunately using the above code in each control or the main form
didn't help too, I'm wondering desperately if there is another way to
fix this annoying problem?

FYI: We are using Visual Studio 2005 / .NET 2.0 running on mainly
Windows XP Professional SP2 on 3GHz multithreaded CPU and 1GB RAM.

Thanks for your help.

Maya

> We have been trying to eliminate flickering issues when loading
> different controls or switching to different views with no luck, and
> have been trying different suggested methods to get rid of the
> flickering such as:
> ....
> Unfortunately using the above code in each control or the main form
> didn't help too, I'm wondering desperately if there is another way to
> fix this annoying problem?

I solve a richtextbox flicker problem with an overlay control. I Add a
label control to my form, set its .Dock to Fill, .Visible to True, and I do
..SendToBack. To freeze the display during complex rtb operations, I use the
overlay control's .BringToFront, and to unfreeze, I use .SendToBack.

I think there is a chance that this technique will work for you, and it is
fairly simple to try out. In my case, my rtb operations cause the rtb to
scroll, and I never see that happen when the overlay is in front. In your
case, you are changing layout, so something may go wrong with this technique.

In my case, I never even see the label overlay. I do BringToFront, then
complex rtb operations, then SendToBack. What I see is the rtb initial
state, then the rtb final state in one paint operation. In your case, some
painting may be coerced by windows during layout operations. If that
happens, you will see the label flash on the form, which will defeat your
purpose. But if all you are doing is changing visibility of controls already
on the form, the technique should work.

One final point, assuming you get the flash of the label as discussed above.
After bringing it to the front, you could validate the overlay's window via
api
BOOL ValidateRect(HWND hWnd, CONST RECT *lpRect);
This will make windows think that the overlay does not need to be painted at
all. I have successfully used this api in a different context without
difficulty. The hwnd is the overlay control's window handle, and you pass
zero/null for the lpRect argument.

Good luck on this challenging problem.

Hi AMercer. Unfortunately your technique doesn't not work for me as the
problem is caused by the form rendering operation itself and not
because the form is busy doing something else while trying to display
controls. Displaying some 10 different items at once is the problem. We
have even tried before setting some sort of mask control (like a label)
to hide all the items in the form until the container control is
initialized and "settled" but that didn't work too



AMercer wrote:
> > We have been trying to eliminate flickering issues when loading
> > different controls or switching to different views with no luck, and
> > have been trying different suggested methods to get rid of the
> > flickering such as:
> > ....
> > Unfortunately using the above code in each control or the main form
> > didn't help too, I'm wondering desperately if there is another way to
> > fix this annoying problem?
>
> I solve a richtextbox flicker problem with an overlay control. I Add a
> label control to my form, set its .Dock to Fill, .Visible to True, and I do
> .SendToBack. To freeze the display during complex rtb operations, I use the
> overlay control's .BringToFront, and to unfreeze, I use .SendToBack.
>
> I think there is a chance that this technique will work for you, and it is
> fairly simple to try out. In my case, my rtb operations cause the rtb to
> scroll, and I never see that happen when the overlay is in front. In your
> case, you are changing layout, so something may go wrong with this technique.
>
> In my case, I never even see the label overlay. I do BringToFront, then
> complex rtb operations, then SendToBack. What I see is the rtb initial
> state, then the rtb final state in one paint operation. In your case, some
> painting may be coerced by windows during layout operations. If that
> happens, you will see the label flash on the form, which will defeat your
> purpose. But if all you are doing is changing visibility of controls already
> on the form, the technique should work.
>
> One final point, assuming you get the flash of the label as discussed above.
> After bringing it to the front, you could validate the overlay's window via
> api
> BOOL ValidateRect(HWND hWnd, CONST RECT *lpRect);
> This will make windows think that the overlay does not need to be painted at
> all. I have successfully used this api in a different context without
> difficulty. The hwnd is the overlay control's window handle, and you pass
> zero/null for the lpRect argument.
>
> Good luck on this challenging problem.