Use of CListCtrl for a live data view?

I'm working on an app which monitors user selected data sets from various devices, and I'd like to display the data in a CListCtrl. This would be very convenient, but I'm just a little concerned about (1) just how fast can a CListCtrl be populated, and (2) how can i reduce or eliminate screen flicker. To be specific...

1. There will likely be upwards of 100 rows of data, maybe more (probably 5 or 6 columns), and I'm going to have to refresh it all as quickly as possible, perhaps as fast as once per second. I can play games and only refresh a visible rectangle, but maybe someone has some experience doing something like this and can give me an idea how responsive the control would be, having all that data deleted and refreshed continually?

2. You can see why I'd be worried about screen flicker, and I thought I'd likely have to make two identical overlapped controls so I could double buffer as I would with a graphic animation, switching the visibility of one or another control after its updated to give the appearance of sudden complete updates. BUT... I see there is an extended style you can set called "LVS_EX_DOUBLEBUFFER", and I wonder if this would help me accomplish the same goal with just one control?

Thanks for any help!

http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx

Quote:

---

Originally Posted by GCDEF

http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx

---

Thanks GC... SetRedraw() defitly works nice and saves me the trouble of double buffering with two whole controls, that's for sure.

Populating 100 rows of 3 columns seems to work within my very scientific time measurement of 'a wink of an eye', so i guess my concern wasn't as bad as i thought. Once upon a time I guess it would have been horrible, but i guess I forget how much a modern processor can do in that "wink of an eye"! :-)

You get also get even better performance from using a virtual list control.

Thanks Arjay. That, and a colleague also suggested I look at a DataGridView.

But I'd like to mess with this CListCtrl a little longer now that I've seen it work so much better than I thought, and one little thing has me confused.

One little mystery left. Since I'm deleting all (myCtrl.DeleteAllItems() ) and then re-populating the ClistCtrl before re-drawing, the only thing NOT very smooth is that if the user has scrolled the list vertically, the scroll position is going to reset to 0 when the delete is done. I thought this would be no problem, as I'd simply save the scroll position ( myCtrl.GetScrollPos(SB_VERT); ) into a static int before deleting and re-populating, and then restoring it ( myCtrl.SetScrollPos((SB_VERT, saveScroll, 1)) after I'm done. But I've just realized that SetScrollPos() really has no effect at all. Neither does myCtrl.ScrollWindow(0, saveScroll,0,0);

Granted, I'd probably avoid the whole issue by keeping my rows intact, and just replacing the specific items that need to change from pass to pass. But I'd still like to know why the above strategy doesn't work, and why I can't re-scroll my list to known valid position. I realize I'm probably violating some basic "Windows 101" issue here, but I can't see it. Any thoughts?

Try this. Before deleting save the index of the topmost visible item (GetTopIndex) and then after re-population make sure that that item is visible (EnsureVisible).

Quote:

---

Originally Posted by Randy C

One little mystery left. Since I'm deleting all (myCtrl.DeleteAllItems() ) and then re-populating the ClistCtrl before re-drawing, the only thing NOT very smooth is that if the user has scrolled the list vertically, the scroll position is going to reset to 0 when the delete is done. I thought this would be no problem, as I'd simply save the scroll position ( myCtrl.GetScrollPos(SB_VERT); ) into a static int before deleting and re-populating, and then restoring it ( myCtrl.SetScrollPos((SB_VERT, saveScroll, 1)) after I'm done. But I've just realized that SetScrollPos() really has no effect at all. Neither does myCtrl.ScrollWindow(0, saveScroll,0,0);

Granted, I'd probably avoid the whole issue by keeping my rows intact, and just replacing the specific items that need to change from pass to pass. But I'd still like to know why the above strategy doesn't work, and why I can't re-scroll my list to known valid position. I realize I'm probably violating some basic "Windows 101" issue here, but I can't see it. Any thoughts?

---

IIRC you need to call SetRedraw and SetScrollPos in the correct order to get the desired behavior. I think you first have to call SetRedraw(TRUE) and then SetScrollPos(...).

D Drmmr,

That combination worked to make the scroll bar move to the right position, but the effect was bizarre. After the update, meaning the next time items were deleted and subsequently refreshed, the list contents appeared as if the scroll bar had been reset to its top most position, even though the scroll bar position got preserved, midway down. Even weirder, manually scrolling up with the scroll bar would then reveal a bunch of seemingly blank rows! :-0

So the more i think of it, it seems that at least with the list control, the best behavior is when the leftmost column (the "Item" ) remains static, as in a simple numbered list, and make sure I only refresh the "subitems" when I refresh. That way the scroll bars will always work right, and the control itself just seems to be more predictable and well behaved.

I don't believe there will be any views in my app where at least one column stays the same so this will probably be best.In fact i think if a case comes up a where I *DO* need to update ALL columns on a recurring basis, it probably would be best to have an unused column 0, set to absolute minimum width and no text displayed, and just use the item's "lparam" if I need to find or identify that row.

Oddly though it may be moot.

Quote:

---

That combination worked to make the scroll bar move to the right position, but the effect was bizarre. After the update, meaning the next time items were deleted and subsequently refreshed, the list contents appeared as if the scroll bar had been reset to its top most position, even though the scroll bar position got preserved, midway down. Even weirder, manually scrolling up with the scroll bar would then reveal a bunch of seemingly blank rows! :-0

---

That's why I suggested using GetTopIndex and EnsureVisible in my post #6:cool:

Quote:

---

Originally Posted by 2kaud

That's why I suggested using GetTopIndex and EnsureVisible in my post #6:cool:

---

2Kbaud: I couldn't figure out how to get that to work. I did use GetTopIndex to obtain an integer index to what I ASSUME is the top item which is visible in the scrolled position. Then, after the rebuild I use that index in EnsureVisible(), and I've tried it with the flag to allow "partial visibility" set either way. It does scroll the display to some position, but now where I wanted.

Quote:

---

Originally Posted by Randy C

...I use that index in EnsureVisible(), and I've tried it with the flag to allow "partial visibility" set either way. It does scroll the display to some position, but now where I wanted.

---

You need to be more specific: what was "some" position and where you wanted it to be?
Some code might help