I was looking at the code on codeproject to solve my listview
flickering issue. All the references to functions in the rest of my
post refer to that code. It's available at
http://www.codeproject.com/cs/miscct...58&msg=1488858
That code didn't solve my problem. I have a ListView (in Details mode)
with about 70 rows and 12 columns. It's a stock ticker kind of app.
When it first starts, each subitems are updated once as data is
received from the server. During that time flickering is so bad, it's
probably epilepsy seisure-inducing. The update messages are coming from
a library at random intervals.
After the initial global update, individual subitems are updated fairly
frequently -- I'd say about 20 subitems per second. The updating for
each subitem includes font color changes, background color changes, and
subitem text changes (no rows/columns are added or removed). Even
during those updates it's still pretty obvious that the background is
being repainted -- it still flickers.
Stepping through the code, it seems like the call to this.Update() in
the function updateItem() returns right away. By the time the WndProc
function gets called, updateItem() has already re-setted the updating
flag to false.
To test out that theory, I commented the line in UpdateItem() that sets
updating to false, rather set it to false in the WndProc function, as
follow:
protected override void WndProc(ref Message messg)
{
if (myUpdating)
{
myUpdating = false;
if ((int)WM.WM_ERASEBKGND == messg.Msg)
{
...
}
...
}
...
}
This made no difference whatsoever. (still don't know why)
I then tried ALWAYS cancelling WM_ERASEBKGND messages, and that worked
(well, I got flicker-free updates (it was beautiful I tells ya!), but
of course scrolling, resizing, etc. didn't work properly).
The library I'm using to get the stock market data is multi-threaded. I
came to the conclusion that a different thread calls the updateItem()
function than what calls WndProc(). I didn't think that was possible.
The class that receives the messages from the 3rd party library
implements ISynchronizeInvoke, and the library properly calls
InvokeRequired, etc, which I thought would force all my code to be
called by the same thread. Apparently not.
Anyway, I suppose if I had a synchronous version of Control.Update()
(the function being called in UpdateItem() between setting the update
flag to true and setting it to false) then everything would be cool. Is
there such a thing?
If anybody has any suggestion on how to solve this, pls let me know :)
I suppose extending the codeproject code with a list of items to update
would do it, but I'm hoping there's something simpler that I'm missing.
