i solved my flickering problems with ListView setting DoubleBuffered property to true.
Now I am wondering:
why is DoubleBuffered set to false by default?
when DoubleBuffered should be kept set to false? Is there any unwanted side-effect when DoubleBuffered is set to true?
I'm asking this because my overridden ListView is always used by my apps with DoubleBuffered=true.
Because it is unnecessary in most situations and requires more resources to perform. Is your ListView flickering when you add a lot of items at once? If so, use the AddRange() method instead. If it is flickering when the mouse hovers over...well, yeah, you may have to use double buffering.
I'm not noticing any side-effect (with DoubleBuffered=true), even on ListViews that have a small amount of items and would not require it.
I was already using AddRange, but it was not sufficient, because there happen very frequent calls to AddRange that cannot be done altogether (data comes from an external device and is put into the ListView, the frequence depends on the device).
I have no more problem with the flickering (I used DoubleBuffered property).
It's just that I wonder why not setting it to true by default in the Framework, when there's no side-effects.
TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!) 2008, 2009 In theory, there is no difference between theory and paractice; in practice there is.
* Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
* How NOT to post a question here
* Of course you read this carefully before you posted
* Need homework help? Read this first
Exactly. Again, you may not notice it, but drawing to a surface first and then blt'ing that image to the active graphics object is more resource intensive. Why use resources that are not needed? I am asking you about the conditions which are causing the flickering. You may be doing something inefficiently. If that is the case, double-buffering is simply a band-aid.
@CPU: I like the Schrödinger analogy
Last edited by BigEd781; November 18th, 2008 at 02:51 PM.
OK, I understand. But do you really think that such a memory allocation could be a problem when working on PC Windows system, with virtual memory and so on? My app is not run under embedded systems with reduced memory availability.
app conditions:
I was already using AddRange, but it was not sufficient, because there happen very frequent calls to AddRange that cannot be done altogether (data comes from an external device and is put into the ListView, the frequence depends on the device).
It's not that we don't like it, but personally I think it may be avoidable and is probably caused by something that you are doing, not a problem with the control. Maybe your conditions do require it, and that is fine. But you don't want to write inefficient code just because taking up a little more memory here and there is easier (you also don't want to get crazy with optimizations. There is a balance). I sounds as if you are adding rows to this listbox quite often, so perhaps double-buffering the control is a fine solution.
I also wonder about why the hell double buffering isn't enabled by default. The most annoying reason I find is that when you start resizing the width of columns in a list view, it literally has an epileptic fit with how much the screen flickers.
If you've ever programmed in MFC, you will find that this annoying flicker DOES NOT occur in the MFC listviews.
Furthermore, why the hell is it a protected property? Everytime I have to double buffer it I must derive my own listview class from the .NET inbuilt one. Why can't it just be simply a public property like most of the other properties?
So it looks like M$ have gone backwards with the listview implementation in .NET. I seriously think it's flawed. What is the justification?
Bookmarks