I wish myself a flicker free form
-
My Form is flickering like hell, maybe because I have a lot of components in it (treeview, textboxes, listboxes, toolbar, menu, statusbar), and i couldn't find any solution for this. Double Buffering with SetStyle didn't work. What can I do to reduce the flickering?
-
My Form is flickering like hell, maybe because I have a lot of components in it (treeview, textboxes, listboxes, toolbar, menu, statusbar), and i couldn't find any solution for this. Double Buffering with SetStyle didn't work. What can I do to reduce the flickering?
ControlStyles.DoubleBuffer- which must be combined withControlStyles.AllPaintingInWmPaintandControlStyles.UserPaintas the documentation states - is only effective when drawing your own forms. It will not simply change how GDI+ renders controls. If you're getting flickering from including controls from the BCL on your form (all of which - at least for those you mentioned - encapsulates the native Common Controls) then you're machine is most likely the problem (or you're taxing the CPU by some pretty hefty code in your form'sOnResizeoverride orResizeevent handler). Check to make sure your monitor's refresh rate is as high as the monitor will support. If you're system doesn't have a lot of memory I recommend getting more memory. Without knowing more it's hard to say, though. Do you have a lot of code in either the override or event handler I mentioned above? Is there anything else going on when your resizing or moving the form around? Do you have 20 instances of VS.NET open? :) Basically, you should not be seeing any flickering (within reason; a Pentium I or II would be bad with, say, XP). Those controls you mentioned are actually the native controls that are wrapped by Windows Forms (so that controls are consistent with the platform, unlike Java AWT or Swing - though controls native to the framework have their advantages, too). If you're not seeing flickering on any of your native applications (like Windows Explorer, for example) then something else is the problem. If you are doing a lot of work in your application when the form moves around or is resized then consider doing that work in a separate thread (if possible) so that the form can be repainted. If you need to update the UI from another thread, be sure to update the UI (i.e., makes calls on it) in the thread on which it was created by using theControl.Invokemethod. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog] -
ControlStyles.DoubleBuffer- which must be combined withControlStyles.AllPaintingInWmPaintandControlStyles.UserPaintas the documentation states - is only effective when drawing your own forms. It will not simply change how GDI+ renders controls. If you're getting flickering from including controls from the BCL on your form (all of which - at least for those you mentioned - encapsulates the native Common Controls) then you're machine is most likely the problem (or you're taxing the CPU by some pretty hefty code in your form'sOnResizeoverride orResizeevent handler). Check to make sure your monitor's refresh rate is as high as the monitor will support. If you're system doesn't have a lot of memory I recommend getting more memory. Without knowing more it's hard to say, though. Do you have a lot of code in either the override or event handler I mentioned above? Is there anything else going on when your resizing or moving the form around? Do you have 20 instances of VS.NET open? :) Basically, you should not be seeing any flickering (within reason; a Pentium I or II would be bad with, say, XP). Those controls you mentioned are actually the native controls that are wrapped by Windows Forms (so that controls are consistent with the platform, unlike Java AWT or Swing - though controls native to the framework have their advantages, too). If you're not seeing flickering on any of your native applications (like Windows Explorer, for example) then something else is the problem. If you are doing a lot of work in your application when the form moves around or is resized then consider doing that work in a separate thread (if possible) so that the form can be repainted. If you need to update the UI from another thread, be sure to update the UI (i.e., makes calls on it) in the thread on which it was created by using theControl.Invokemethod. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]I don't think that the problem is dependent from my machine. I have a Athlon 2200+ CPU and 500 Megabytes RAM and it also happens without having the CPU loaded. And it flickers as much as it does on my 1.5Ghz Notebook. And yes I have a OnResize Event but commented out it's content. (it flickers on both ways) I'll try to create a new Project and copy all forms from my original program to see if my program causes that flickering. Thanks for investing so much (writing-)time for this :)
-
I don't think that the problem is dependent from my machine. I have a Athlon 2200+ CPU and 500 Megabytes RAM and it also happens without having the CPU loaded. And it flickers as much as it does on my 1.5Ghz Notebook. And yes I have a OnResize Event but commented out it's content. (it flickers on both ways) I'll try to create a new Project and copy all forms from my original program to see if my program causes that flickering. Thanks for investing so much (writing-)time for this :)
TyronX wrote: And yes I have a OnResize Event but commented out it's content. There is no
OnResizeevent. If you overrideOnResizeyou must either comment the entire definition of the method (including the method itself) or callbase.OnResize, passing the parameters you were given. When you override a method you are being called in place of the base class's implementation. Often times the base class implements something in that handler, besides firing the event. So, if you are overriding it callbase.OnResizeor comment out the whole thing. If you're handling theResizeevent than this isn't a problem (only with cancelable events like those defined asCancelEventHandlercan you cancel whatever implementation the base event handler allows, like setting a property or losing focus for things like input validation). This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog] -
TyronX wrote: And yes I have a OnResize Event but commented out it's content. There is no
OnResizeevent. If you overrideOnResizeyou must either comment the entire definition of the method (including the method itself) or callbase.OnResize, passing the parameters you were given. When you override a method you are being called in place of the base class's implementation. Often times the base class implements something in that handler, besides firing the event. So, if you are overriding it callbase.OnResizeor comment out the whole thing. If you're handling theResizeevent than this isn't a problem (only with cancelable events like those defined asCancelEventHandlercan you cancel whatever implementation the base event handler allows, like setting a property or losing focus for things like input validation). This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]