0

I've replaced the normal treeview to allow double buffering as show here.

But I realized that after long hours of use the tree view would turn blank/white, but my nodes are still there and I can still click on them.

The bug seems hard to replicate as it requires a substantial hours of use, and I really can't figure out why.

Not sure of anyone as seen this issue or have any idea how to get around it.

albusSimba
  • 441
  • 4
  • 14
  • You can call `SetStyle(ControlStyles.OptimizedDoubleBuffer, true);` in the constructor of your Custom Control. The BufferedGraphics is handled in managed code. -- The .Net Framework version matters (it doesn't matter anymore if .Net 5+ is used). – Jimi May 22 '21 at 13:17
  • Unfortunately it is coded for .Net 4.5 – albusSimba May 22 '21 at 14:06
  • Update to at least .Net Framework 4.7.2, but of course 4.8 should be the right choice (there's actually no reason to use a .Net Framework version prior to this one). – Jimi May 22 '21 at 14:10
  • I wish I could. but the max I can go is 4.5.2 – albusSimba May 22 '21 at 14:12
  • Is it a constraint determined by System version? I.e., your app needs to work on very old Systems? .Net Framework 4.8 is installed in all Windows 10 Systems and most Windows 7 Systems (well, right, of course if the users actually let their System update). WinForm is a Desktop framework, so the usual *Server Farm which refuses to update their Systems* doesn't apply :) – Jimi May 22 '21 at 14:14
  • Yes my app need to work on very old Systems and the users I work with refuses to update their system. In fear of stability issues. Yes its a server farm. T.T – albusSimba May 22 '21 at 14:16
  • All right, not good for you, anyway the BufferedGraphics has actually been part of the Framework from a long time. Of course it works better in .Net Framework 4.7.2+, but it also works in .Net 4.5.2. -- It won't fix any mistake in handling custom Graphics, if any. If the TreeView is OwnerDrawn, it has to be done very carefully, you can't leak even a Pen object. – Jimi May 22 '21 at 14:20
  • Erm if I use images as little icons in each nodes. will it affect it too? – albusSimba May 22 '21 at 14:22
  • It depends on how it's done. If you pre-load an ImageList and dispose of the ImageList correctly (disposing of all its content) when the Container Form is closed, you should have no problems. If you instead use Graphics from Resources - and the part that disposes of these objects is neglected - , I'd be surprised if it doesn't give up in ~24 hours. You run out of both handles and Graphic resources. The more immediate - visual - effect of Graphic resources starvation is a blank Control. – Jimi May 22 '21 at 14:24
  • It is done by preloading an imagelist, but the code is auto generated. Do I have to do anything else to dispose it? Or did I miss a trick here? – albusSimba May 22 '21 at 14:28
  • I don't know anything about your app and how it handles its stuff, I can just talk about a general use-case. Anyway, as mentioned, if you see blank Controls (or Containers with *black holes* instead), the cause can be Graphic starvation (exhausted Graphics resources). – Jimi May 22 '21 at 14:30
  • Would turning on double buffering be a factor for the issue or is it a non factor? – albusSimba May 22 '21 at 14:33
  • If you're leaking Graphic resources / handles, DoubleBuffering doesn't solve anything, of course (I cannot say whether it can make it worse, that's determined by code analysis and a Profiler). You have to *cure* the source of the problem. – Jimi May 22 '21 at 14:34
  • do killing the object and restarting it, restores normal functionality, indicate there is a leaking graphic resource? – albusSimba May 22 '21 at 15:19
  • Sorry, I don't know what *killing the object and restarting it* means. -- You have to dispose of all disposable objects you create. – Jimi May 22 '21 at 16:58

0 Answers0