No announcement yet.

DC madness..

  • Filter
  • Time
  • Show
Clear All
new posts

  • Borje Hagsten
    Paul, seems to be something wrong with it, yes. Have to look into that..

    Chris, the weird thing is, with CS_OWNDC, PARENTDC or none declared at all,
    problem still is there. CS_CLASSDC is the only one that provides a fix for
    this particular problem. It's a tricky one, since the problem only occurs
    after a while and disappears directly when the DC is refreshed.

    Seems like the problem is within the DC itself. BTW, the article at MSDN
    says something about "use CS_OWNDC sparsely in Win95", because it means
    using up +800 bytes per Window of the 64KB GDI resource heap. Same thing
    probably applies to Win98.

    I tested with some other of my controls, like the Virtual listbox, and
    using CS_CLASSDC actually gives a tiny bit better performance at redraw
    and scroll there too. Interesting..


    Leave a comment:

  • Chris Boss

    I think what you want is CS_OWNDC !

    Using CS_CLASSDC makes all the controls of your class use the
    same DC. CS_OWNDC allows each instance of your control to have its
    own DC.

    If you only need one control of your custom class, CS_OWNDC should
    work well. If you need many instances of the custom control, then
    CS_CLASSDC should be used to save GDI memory (each DC uses 800 bytes).


    [This message has been edited by Chris Boss (edited May 14, 2001).]

    Leave a comment:

  • Paul Noble
    Hi Borje,

    Sorry, not on-topic, but is your algonet e-mail working at the
    moment ?

    Thanks -

    Leave a comment:

  • Borje Hagsten
    started a topic DC madness..

    DC madness..

    Tip for those of you who like to write custom controls: I had some
    minor problems in my editor - sometimes scrolling slowed down and
    became "jerky". No matter how I tried, I couldn't find a solution.
    Control could work fine for hours and then suddenly this problem came up.

    The editor uses a memDC which is refreshed in WM_SIZE, to keep all
    things down to a minimum but still handle eventual resize, etc. Funny
    thing was that when this problem occurred, simple resize and thereby
    refresh of DC made everything ok again. Led me to suspect some sort of
    memory fragmentation, whatever, occurred in the control's DC after a while.

    Looked around at MSDN and found interesting page about Window Classes at

    So, started experimenting with the Window class I use for it and found
    that using CS_CLASSDC instead of CS_PARENTDC in WNDCLASS style solved
    the problem, plus actually made repaint/scrolling a tiny little bit faster.

    Control has been in use for +5 hours now, no problem at all. May not
    apply to all types of controls, but can be worth experimenting with..