Shoutbox

OK, I tried searching the forums for similar but couldn't find anything.

Test case:

• Plus! -> Open Chat Log
  
• Notice that the list of log files flickers [edit]while the tree control is being populated[/edit]

Is this just a case of needing a WM_SETREDRAW(FALSE) / WM_SETREDRAW(TRUE) pair around the code which is populating the tree control, possibly with a IDC_WAIT cursor while it's doing that?

I don't get flicker once the list is populated.

I am also unable to reproduce this issue?

Original post edited. My bad for assuming that people on a technical forum would take that as read.

It has always flickered on my computers after version 4.50 of Plus! while loading the folders in that list.

I think that is something about the improvements on Log Viewer which has been done at version 4.50, but I don't care it that much.

I really don't think this is a major issue, or even a minor one, but flickering never looks pretty, so it may be worth fixing in the next release.

quote:

---

Originally posted by RaceProUK
I really don't think this is a major issue

---

I'd agree with that.

quote:

---

Originally posted by RaceProUK
or even a minor one, but flickering never looks pretty, so it may be worth fixing in the next release.

---

If it's as easy as the change I suggested, it's just another example of MS's poor design with parts of the UI, as a WM_PAINT ought to be the lowest priority message but instead gets forced for every update to the control.

The same happens for list and combo boxes, I believe.

Ah well, if it can be scheduled for the next release I'll be happy, as it's one of those minor irritants which detracts from what is otherwise a first-rate product.

quote:

---

Originally posted by Click
it's just another example of MS's poor design with parts of the UI

---

I wouldn't necessarily go that far; after all, if you're adding one element, it's a nuisance to force a redraw afterwards.

There's a difference between invalidating the control and allowing the next WM_PAINT to redraw it when it's convenient, and forcing a repaint unless SETREDRAW has been explicitly turned off.

WM_PAINT is the lowest priority message and gets special handling anyway to stop multiple paint messages being sent in quick succession; this should have been exploited rather than MS taking the lazy approach and repainting it every time something was changed, even if that has no visible effect, as is often the case.