Prev: CMFCRibbonStatusBar always visibile
Next: Marshalling C# Strings to VC++ 6.0‏‏
From: Doug Harrison [MVP] on 14 Apr 2010 13:55
On Wed, 14 Apr 2010 11:25:36 -0400, Joseph M. Newcomer
<newcomer(a)flounder.com> wrote:

>In this case, he is creating a bitmap which is in the class, so it can have a lifetime
>beyond this subroutine.

Yes, I believe I said as much in my first message.

--
Doug Harrison
Visual C++ MVP
From: "Bill" don't want more on 15 Apr 2010 04:49
I wasn't aware of CClientDC. Thanks, I'll look into it. It will make some of
my code nicer.
I thought GetDC just gave a pointer to the window's DC. I didn't realize it
created something that needed to be released.

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:abnbs5pcikd11f2vjfinj7m6uedbfm13gk(a)4ax.com...
> See below...
> On Tue, 13 Apr 2010 23:47:54 -0500, "Doug Harrison [MVP]" <dsh(a)mvps.org>
> wrote:
>
>>On Wed, 14 Apr 2010 11:25:40 +0800, "Bill" <<don't want more spam>> wrote:
>>
>>>Per Joe's suggestion, I do DeleteObject on the bitmap now. I can't find a
>>>function to DeleteObject for the memoryDC. Is there one or a way?
>>
>>There is the DeleteDC function. However, it should be called automatically
>>when the object is destroyed if you are using CDC and have called a Create
>>function.
>>
>>>Also, I saw in DeleteObject help that I shouldn't delete an object that
>>>is selected
>>>into a DC. But I can't find a function to unselect the bitmap object out
>>>of
>>>the DC. Am I overlooking one or must I just select another object (maybe
>>>a
>>>stock object) into the DC?
>>
>>Standard practice is to save the object that was returned by SelectObject
>>and select it back into the DC. You can also use SaveDC/RestoreDC, which
>>is
>>simpler. You should wrap SaveDC/RestoreDC with a class that uses the RAII
>>technique, which helps with exception safety and clarity, as using such
>>classes will significantly shorten your code as it helps you make your
>>program more robust. That is, you should be able to write inside a
>>function:
>>
>>DcSaver dcSaver(dc);
>>
>>After this statement is executed, you can use the DC to your heart's
>>content. When the DcSaver goes out of scope and is destroyed, the DC will
>>be restored. If you're not familiar with this technique, let me know, and
>>I'll post an implementation of DcSaver. Again, codeproject.com may have an
>>implementation of this.
>>
> ****
> I have an RAII version of SaveDC on my MVP Tips site.
>
> Also, I am not at all sure why a GetDC is being done; it should be
>
> CClientDC dc(wnd);
>
> where wnd is the CWnd * pointer in hand; the DC will be released when the
> variable goes
> out of scope.
> ****
>>>I'm not sure I have a good mental image of what is happening with bitmap
>>>and
>>>DC classes and instances and objects and handles. Is it correct to
>>>imagine
>>>this? Before MFC, these (SDK?) objects were referenced by handles. MFC
>>>added
>>>a layer around these objects to allow C++ coding using them. So to use
>>>MFC,
>>>there is an instance of the MFC class but still the original windows
>>>object.
>>>Attach and detach make and break the connection between these two things
>>>via
>>>pointers or lookup tables. Are the original windows objects "stable" in
>>>that
>>>they can be referenced by their handle through the life of the program?
>>
>>That depends on the Windows object and when it's destroyed. It is
>>certainly
>>possible to have MFC objects that contain NULL handles, but it's harder to
>>encounter an MFC object that contains an invalid, non-NULL handle.
>>Observing that condition usually represents a bug in your code.
>>
>>>Is it only the MFC class instance that might be temporary in that it
>>>might be
>>>destructed when it goes out of scope but the windows object referenced by
>>>the handle is still there?
>>
>>Sure, that can happen. The destruction of a temporary MFC object will not
>>destroy the underlying Windows object, because the MFC object doesn't own
>>it. Indeed, the Windows object may have been destroyed by the time MFC
>>gets
>>around to deleting the temporary MFC object that wraps it. That said,
>>ownership in MFC is often less than clear, and the documentation typically
>>doesn't help. This is when you use the source. Note also that these
>>temporary MFC objects are all referred to by pointers, so strictly
>>speaking, they aren't destroyed when they "go out of scope". They're
>>destroyed primarily during idle-time processing, when you drop back into
>>MFC's message loop.
> ****
> The default CWinApp::OnIdle handler goes through the handle map, locates
> all temporary
> handles, and deletes the MFC object without deleting the underlying kernel
> object which is
> wrapped by the temporary object. So after returning to the default
> message pump, the
> pointeres to temporary MFC objects are destroy.
>
> In this case, he is creating a bitmap which is in the class, so it can
> have a lifetime
> beyond this subroutine.
> joe
> ****
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


First  |  Prev  | 
Pages: 1 2 3
Prev: CMFCRibbonStatusBar always visibile
Next: Marshalling C# Strings to VC++ 6.0‏‏