Thanks.
I fully unfderstand your point, as I wrote I was ashamed of my code.
I did not see a clever way to do it. My problem was to understand how to
repaint the area below the zoomed button, after removing it. I will follow
"Joseph M. Newcomer" wrote:
See below...
Key here is that you seem to be doing a lot of work to solve a problem that should not
need to be solved. The correct way to "show a zoomed image" is not to just splatter
pixels on the screen, but to simply display a window that has the content you want. By
using a window, you get the benefit of all the existing mechanisms that handle this
correctly.
I see a massive amount of effort here to solve a problem that does not need to be solved.
I've done this many times, and not once have I hever needed a windowDC, or had to BitBlt
anything to a random place on the screen; you can write the code in minutes, and it works
the first time.
Derive a window from CWnd that has an OnPaint handler that draws the zoomed button. Then
all you need to do is supply it with the image to draw. That takes almost no effort.
This is the most convoluted code I've ever seen to solve a trivial problem. Rethink what
you are doing, and design something better, that does not splatter bits onto the screen
randomly. If you aren't writing to the client area of your window, you shouldn't be doing
it.
joe
On Tue, 2 Dec 2008 08:18:06 -0800, Laurs <Laurs@discussions.microsoft.com> wrote:
Hi
my code which is long
CWnd *pwnd = AfxGetMainWnd();
CWindowDC dc(pwnd); // screen DC--I won't actually draw on it
****
If you aren't going to use it, why do you create it at all?
****
int idc = dc.SaveDC();
****
Since you aren't going to draw on it, why are you bothering to save its state?
****
CDC cdcSave;
RECT rect, rectorg;
RECT rectCompatible;
CDC hdcCompatible;
rect.left = p.x-2;
rect.right = p.x + __iinticonsize +4;
rect.top = p.y -2;
rect.bottom = p.y +__iinticonsize +4;
//save screen in rectangel------------------------------------------
rectorg.left = p.x-2;
rectorg.right = p.x + w - 6;//p.x+36
rectorg.top = p.y -2;
rectorg.bottom = p.y + h - 6; //p.y+36
//I see at least 2 Handle leaks here:
cdcSave.CreateDC("DISPLAY", NULL, NULL, NULL);
int icdcSave = cdcSave.SaveDC();
****
Given you have saved the DC, there is no need to ever restore anything to it; you just
call RestoreDC and it all restores to this point.
****
//if first create global restore data
if (_iflgbmpfirst) {
****
Note that it is very poor style to start names with _; this is reserved for compiler
vendors.
****
_iflgbmpfirst = EFLGFAL;
****
What is an EFLGFAL? Am I supposed to have a clue as to what this symbol means? How can I
diagnose code that uses symbols that make no sense?
****
_cdcSave.CreateCompatibleDC(NULL);
HBITMAP hbmSave = CreateCompatibleBitmap(dc, w+2, h+2);
****
I didn't see where this is deleted. That will use up a handle each time through this code
****
originalhbmSave = SelectObject(_cdcSave, hbmSave);
****
Given you have done a SaveDC, there is no reason to save this value
****
if (!originalhbmSave) {
AfxMessageBox("Bitmap error", MB_OK);
}
}
//save picture and position below of the area we want to
//draw enlarged button in
_cdcSave.BitBlt(0,0,w,h,&cdcSave,rectorg.left,rectorg.top,SRCCOPY);
_xPos = rectorg.left;
_yPos = rectorg.top;
****
This overuse of _ at the start of identifiers is making the code unreadable
****
//
rectCompatible.left = 0;
rectCompatible.right = __iintbtnsize;
****
The doulbe-underscore prefix __ is specifically used for vendor-specific extensions to the
C/C++ language. Its use by end programmers is extremely inappropriate
****
rectCompatible.top = 0;
rectCompatible.bottom = __iintbtnsize;
_iflgbltsave = EFLGTRU;
****
What is an EFLGTRU?
****
//create memory DC to do the drawing in
hdcCompatible.CreateCompatibleDC(NULL);
MICINT ihdcCompatible = hdcCompatible.SaveDC();
*****
What the h*** is a 'MICINT'? The return type of SaveDC is explicitly said to be an int,
and that is the data type you should use here!
****
HBITMAP hbmScreen =
CreateCompatibleBitmap(dc, __iintbtnsize,
__iintbtnsize);
originalhbmScreen = SelectObject(hdcCompatible, hbmScreen);
****
Given you have saved the DC, there is no need to save this value
****
if (!originalhbmScreen) {
AfxMessageBox("Bitmap error", MB_OK);
****
That's _T("Bitmap error")
****
}
PxLib::FillRect(hdcCompatible, &rectCompatible,
GetSysColor(COLOR_3DLIGHT));
RECT rr;
rr.left=rectCompatible.left;
rr.right=rectCompatible.right;
rr.top=rectCompatible.top;
rr.bottom=rectCompatible.bottom;
hdcCompatible.DrawEdge(&rr, BDR_RAISEDINNER, BF_RECT);
m_ilButtons.Draw(&hdcCompatible, iintbtn, CPoint(2,3), iflag_);
cdcSave.StretchBlt(rect.left,rect.top,w,h,&hdcCompatible,0,0,
__iintbtnsize,__iintbtnsize,SRCCOPY);
****
Why isn't this code just in an OnPaint handler for the CWnd which handles the zoomed
display? Note that the code that assumes that the contents of the windows which are not
under control of this program are going to be the same across the capture and restore is
not a safe assumption. You may not safely make this assumption. I can give several
counterexamples, but they should be obvious.
****
RECT redge;
redge.left = rect.left;
redge.right = rect.left + w;
redge.top = rect.top;
redge.bottom = rect.top + h;
cdcSave.DrawEdge(&redge, EDGE_ETCHED, BF_RECT); //EDGE_ETCHED EDGE_RAISED
redge.left = rect.left+1;
redge.right = rect.left + w -1;
redge.top = rect.top + 1;
redge.bottom = rect.top + h -1;
cdcSave.DrawEdge(&redge, BDR_RAISEDINNER, BF_RECT); //EDGE_ETCHED EDGE_RAISED
_icountdraw++;
if (originalhbmSave) {
//SelectObject(_cdcSave, originalhbmSave);
}
if (originalhbmScreen) {
SelectObject(hdcCompatible, originalhbmScreen);
}
****
Just call SaveDC and the objects are deselected! There is no need for the above lines of
code.
****
DeleteObject(hbmScreen);
hdcCompatible.RestoreDC(ihdcCompatible);
hdcCompatible.DeleteDC();
****
No need for this, the destructor will do it
****
cdcSave.RestoreDC(icdcSave);
****
I presume there was a reason for saving the DC, but you never took advantage of this. You
are restoring values manually. That's a waste of effort
****
cdcSave.DeleteDC();
****
This is handled by the destructor
****
dc.RestoreDC(idc);
The _cdcSave
is a global DC that i use to save the bitmap in, to restore the screen from
****
Do NOT use _ for these names
****
MCCButtonDelete(
int iflgcln_ //< clean up, delete the
) {
****
Is this supposed to be a function definition? It has no return type; it has funny names
that end in _ (almost as bad as starting with _), it has some of the weirdest formatting
I've ever seen
****
if (_iflgbltsave) {
CWnd *pwnd = AfxGetMainWnd();
CWindowDC dc(pwnd); // screen DC--I won't actually draw on it
****
Then why are you bothering to get it?
****
int save = dc.SaveDC();
****
Given you aren't using the DC, why are you bothering to save its state?
****
int h,w;
****
Do not use commas in declaration lists; one variable, one line
****
h = w = __iintbtnsize * __iintbtnzoomfactor; //42
_iflgbltsave = EFLGFAL;
****
What is an EFLGFAL?
****
_icountdraw--;
CDC cdcSave;
cdcSave.CreateDC("DISPLAY", NULL, NULL, NULL);
****
Why do you need a display DC anyway?
****
cdcSave.BitBlt( _xPos, _yPos, w ,h, &_cdcSave,0,0,SRCCOPY);
cdcSave.DeleteDC();
****
The destructor handles this.
****
dc.RestoreDC(save);
****
Why are you bothering to restore a DC you didn't use and aren't modifying?
****
}
if (iflgcln_) {//clean up
_cdcSave.DeleteDC();
_iflgbmpfirst = EFLGTRU;
****
Am I supposed to know what an EFLGTRU is?
****
}
}
So its weird. I hope you can follow my way to do it, and maybee can give a
solution.
Laurs
"Joseph M. Newcomer" wrote:
The most common cause of losing handles is to delete an object while it is still selected
into a DC. The most common cause of this in MFC is
... stuff here
CPen red(...stuff here...);
dc.SelectObject(&red);
...do some drawing
}
Note that ~CPen is called while the pen is still selected. What happens is that when
~CPen is called, it calls CGDIObject::DeleteObject which calls ::DeleteObject on the
handle of the object. But if the object is selected into a DC, the object is not deleted,
and therefore leaks.
Key here is to either select the original pen back in
CPen * oldPen = dc.SelectObject(&red);
... do some drawing
dc.SelectObject(oldPen);
or better still, use SaveDC/RestoreDC:
int save = dc.SaveDC();
... stuff
CPen red(...);
dc.SelectObject(&red);
... drawing
dc.RestoreDC(save);
the RestoreDC restores the DC to its saved state, thus deselecting the pen, so when the
destructor is called, the object is actually deleted.
This is the most common cause I've seen of GDI resource leaks in MFC code. The same error
applies in raw Win32 programming, e.g.,
HPEN pen;
pen = CreatePen(PS_SOLID, 0, RGB(...));
SelectObject(dc, pen);
... drawing
DeleteObject(pen);
which is actually what the MFC code I showed is doing. So look for those situations
first.
joe
On Tue, 2 Dec 2008 06:26:07 -0800, Laurs <Laurs@discussions.microsoft.com> wrote: