hDC lifetime

  • Thread starter Thread starter Chuck Bowling
  • Start date Start date
C

Chuck Bowling

Does the device context handle for a graphics device change during the
lifetime of the underlying object?

I'm asking because I ran across some code that stores the hDC in the class
rather than call Graphics.GetHdc in the OnPaint method.
 
Chuck Bowling said:
Does the device context handle for a graphics device change during the
lifetime of the underlying object?

I'm asking because I ran across some code that stores the hDC in the class
rather than call Graphics.GetHdc in the OnPaint method.
Click to expand...

Theoretically you could, but you might get broken by future releases.
Imagine if MS decided that to change GetDC so that it wouldn't return the
underlying DC but rather a compatible DC, and then would blit the drawing
across on ReleaseDC. Suddenly your preciously held hDC would be worthless.
I'm assuming of course that ReleaseDC is called soon after GetDC.
 
Yes, this can be a serious problem. You should call ReleaseDC as soon as
possible. I assume if it's holding onto the handle, that it's not releasing
the DC. DCs are a very prescious resource. The number of available DCs at
any one time is very low. Something like 8, maybe less, if I recall
correctly.

So by not releasing it, you could run into problems where other, well
behaving apps, could find that there are no DCs available for them to do
their painting.

The DC may not change, but that's not the problem. The problem is that there
just aren't many of them.

Pete
 
Sean Hederman said:
Theoretically you could, but you might get broken by future releases.
Imagine if MS decided that to change GetDC so that it wouldn't return the
underlying DC but rather a compatible DC, and then would blit the drawing
across on ReleaseDC. Suddenly your preciously held hDC would be worthless.
I'm assuming of course that ReleaseDC is called soon after GetDC.
Click to expand...

Yes it is. The GetHdc is followed immediately by a ReleaseDC and the DC is
stored in a variable. It appears to work but I get what you're saying.
Thanks.
 
Well actually, the DC is being released immediately. That's what I was
puzzled about. GetHdc aquires the handle and stores it as an IntPtr then
ReleaseHdc is called. Afterwards the IntPtr is used to draw with.
 
Chuck Bowling said:
Well actually, the DC is being released immediately. That's what I was
puzzled about. GetHdc aquires the handle and stores it as an IntPtr then
ReleaseHdc is called. Afterwards the IntPtr is used to draw with.
Click to expand...

So what's happenning is that the code is using knowledge about how the class
operates internally in order to work. It's a serious breaking of
encapsulation.
 
Sean Hederman said:
So what's happenning is that the code is using knowledge about how the
class operates internally in order to work. It's a serious breaking of
encapsulation.
Click to expand...

Just to add to the pot, I just thought of something that *should* break the
code you're talking about: double-buffering. When the DoubleBuffer style is
set, the Graphics object passed to the Paint methods/events is not the
controls Graphics object, but rather an in-memory bitmap. Keeping the hDC of
this around would be useless at best. So, enabling double-buffering would
break the existing code. Not good.
 
Back
Top