|
I do some draw action:
void CMyView::OnPaint()
{
CPaintDC dc(this); // device context for painting
if( m_bDraw == FALSE )
return;
/**/
CDC* pDC = GetDC();
CDC cacheDC;
VERIFY( cacheDC.CreateCompatibleDC( pDC ));
if( m_pBitmap == NULL )
{
m_pBitmap = new CBitmap;
VERIFY( m_pBitmap->CreateCompatibleBitmap( pDC, m_ClientRect.Width(), m_ClientRect.Height() ) );
}
CBitmap* pOldBmp = cacheDC.SelectObject( m_pBitmap );
//Draw background
CRect rect( m_ClientRect );
cacheDC.FillSolidRect( &rect, RGB(255, 255, 255) );
//cacheDC.Rectangle( rect );
cacheDC.Draw3dRect( &rect, RGB( 0, 0, 0 ), RGB( 255, 255, 255 ) );
//!! Some draw actions here, use cacheDC
pDC->BitBlt( m_ClientRect.left,
m_ClientRect.top,
m_ClientRect.Width(),
m_ClientRect.Height(),
&cacheDC, 0, 0, SRCCOPY );
cacheDC.SelectObject( pOldBmp );
cacheDC.DeleteDC();
}
When I open tha "TaskManager", I notice that the memory usage of My app is increase, what's wrong with my draw method?
I'm amumu, and you?
|
|
|
|
|
You are not deleting your m_pBitmap after you are done with it. Your code should look like this:
cacheDC.SelectObject( pOldBmp );
cacheDC.DeleteDC();
m_pBitmap->DeleteObject();
|
|
|
|
|
1.I have tried your method, Now, if I send the WM_PAINT to view on mouse click, it seems no effect, but if I delete the clause, it can work properly.
2.If you choose a new object for CDC, for example CPen, CBrush, etc, must you do the DeleteObject() on exit?
3.If I use the this->GetDC() to draw directly, does it cause memory leak or allocated but not freed? I notice the memory is increasing when use the view's CDC directly.
I'm amumu, and you?
|
|
|
|
|
qf0421 wrote:
1.I have tried your method, Now, if I send the WM_PAINT to view on mouse click, it seems no effect, but if I delete the clause, it can work properly.
Do not send a WM_PAINT message directly, instead do either one of these two things to force a repaint.
InvalidateRect(hWnd, NULL, TRUE);
UpdateWindow(hWnd);
RedrawWindow(hWnd, NULL, NULL, RDW_ERASE | RDW_INVALIDATE | RDW_UPDATENOW);
qf0421 wrote:
2.If you choose a new object for CDC, for example CPen, CBrush, etc, must you do the DeleteObject() on exit?
Yes, if you create a new brush, pen, palette or bitmap, you must select the original GDI Object back into the DC, and then delete your GDI Object that you allocated.
qf0421 wrote:
3.If I use the this->GetDC() to draw directly, does it cause memory leak or allocated but not freed? I notice the memory is increasing when use the view's CDC directly.
You should not call GetDC from inside of your paint handler. You should use BeginPaint, or the CPaintDC (Which internally calls BeginPaint). Then when you are done with a DC you need to release the DC, otherwise it will use up system resources. If you call BeginPaint to get the DC, then you will need to call EndPaint to release the Dc. If you call GetDC, GetWindowDC, or GetDCEx then you will need to call ReleaseDC to free the DC resource.
|
|
|
|
|
Thank you for your help and code, I have got it
I'm amumu, and you?
|
|
|
|
|
You also need to call
pDC->ReleaseDC() ;
Roger Allen
Sonork 100.10016
If I'm not breathing, I'm either dead or holding my breath.
A fool jabbers, while a wise man listens. But is he so wise to listen to the fool?
|
|
|
|
|
How Can I get MFC support in ATL EXE COM Server project?
I want my program like MS Word!
|
|
|
|
|
Help,
The post that I've been dreading. A post that I do not know the answer to. One of my members wants to know how to create custom types, eg. an unsigned int of 8 bits
http://www.jyse.com/phpBB2/viewtopic.php?p=129#129
please help.
|
|
|
|
|
Create a type using bitfields. For example
struct strtype
{
unsigned p1:2;
unsigned p2:3;
unsigned p3:5;
unsigned p4:5;
};
Creates a struct which holds four fields, one of two bits, one of three, and two of five.
Naturally I'd presume you'd create a class and provide all the operators necessary to deal with it, like operator =, operator <, etc.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
Christian, I hope you don't mind me cutting and pasting this onto Jyse.com
|
|
|
|
|
I would think you should probably ask Chris.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I've inserted a CDialog as a child of an MDI window with the following code:
m_pDlg = new CMyDlg(FromHandle(m_hWndMDIClient));
m_pDlg->Create(IDD_MYDIALOG, FromHandle(m_hWndMDIClient));
m_pDlg->SetFocus();
m_pDlg->ShowWindow(SW_SHOW);
This works fine however no matter what the title bar stays gray even while I'm actively working inside the dialog.
I reposted this because everyone seemed to be asleep last night when I first posted it. Sorry if you happened to read it twice
Any ideas?
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
AFAIK, only top-level windows can be active. MFC fakes activation for MDI child windows by maintaining an internal active frame, and manually sending WM_NCACTIVATE with the appropriate parameters to the frames. This much i gathered from a quick browse through winfrm.cpp anyway.
If all you care about is getting rid of the gray title bar, you can easily send WM_NCACTIVATE to your dialog to accomplish this; however, you may want to consider using a CFrameWnd -derived class for this purpose, as it will function better along with the other MDI children (CTRL+Tab handling for instance).
Sometimes i only remember, The days when i was young Nowadays no one remembers when they were young and stupid... ADEMA, The Way You Like It
|
|
|
|
|
Sending WM_NCACTIVATE worked!
Thanks,
Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
I have a class CMyDialog derived from CDialog.
How can I create a DialogBar from this class instead of a dialog template resource ?
Thank for attention.
|
|
|
|
|
I was inspired by the STL tutorials. So I thought I would try to use some of it. Nothing complicated, just store some integers in a set<int>. But then when I do this set.find(n) where n=26 it gets an access violation. I remember hearing that STL doesn't do much error checking but really.
Is there something obvious I'm missing? Christian? Anybody?
Cathy
Life's uncertain, have dessert first!
|
|
|
|
|
What does all of the code look like?
are you assigning the result of find to an iterator?
typedef set<int> intSet;
typedef intSet::iterator intIter;
...
intSet ints;
intIter iter;
...
iter = ints.find(26);
|
|
|
|
|
Nope.
The offending line is part of a condition in a for loop:
dcodesUsedByCustoms.find(nDCode)!=dcodesUsedByCustoms.end()
nDCode=26, is a local int.
dcodesUsedByCustoms is a set<int>. It's a static class member variable.
Why do you have any ideas?
Cathy
Life's uncertain, have dessert first!
|
|
|
|
|
I don't know of any apparent problems right off of the top of my head. I tried a small little sample program with a set as a static member varaible and I didn't have any problems. If you can post some code that would really help me help you.
|
|
|
|
|
When I comment out a completely unrelated piece of code it doesn't crash:
aperturePtrsIterator it;
for (it=aperturePtrs.begin(); it<apertureptrs.end(); it++)
="" {
="" (*it)-="">bHaveOutputDCodeDef=false;
}
where aperturePtrs is a class member defined:
vector<codbaperture *=""> aperturePtrs;
and aperturePtrsIterator is defined:
typedef std::vector<codbaperture *="">::iterator aperturePtrsIterator;
There is probably something I'm doing wrong here. I'm trying to store pointers to CODBAperture objects that are stored somewhere else in a linked list type of thing. Does (*it) create an instance of CODBAperture?
Cathy
Life's uncertain, have dessert first!
|
|
|
|
|
If you rule out problems created by your code, perhaps there's a Dinkum library error that has been fixed?
Not that I've ever seen an error like this. My first guess is a bug in your code, overwriting something it shouldn't.
|
|
|
|
|
Mike Nordell wrote:
"If you rule out problems created by your code, perhaps there's a Dinkum library error that has been fixed?"
Thanks for the link! I didn't know about this.
Mike Nordell wrote:
"Not that I've ever seen an error like this. My first guess is a bug in your code, overwriting something it shouldn't."
Yes, I think that's what it is. I commented out a completely unrelated piece of code:
aperturePtrsIterator it;
for (it=aperturePtrs.begin(); it<aperturePtrs.end(); it++)
{
(*it)->bHaveOutputDCodeDef=false;
}
where aperturePtrs is a class member defined:
vector<CODBAperture *> aperturePtrs;
and aperturePtrsIterator is defined:
typedef std::vector<CODBAperture *>::iterator aperturePtrsIterator;
There is probably something I'm doing wrong here. I'm trying to store pointers to CODBAperture objects that are stored somewhere else in a linked list type of thing. Does (*it) create an instance of CODBAperture?
Cathy
Life's uncertain, have dessert first!
|
|
|
|
|
Sorry for the late response.
Cathy wrote:
I commented out a completely unrelated piece of code:
That piece of code is definitely not unrelated, and it's also completely wrong.
You shall never, I repeat never, compare an iterator to any other iterator than for equality or inequality. Even that a vector is to be contigous, there is AFAIK nothing stating that a vector iterator has to be implemented as a pointer to the contents, why something like:
if (it < coll.end())
is incorrect code. It should be
if (it != coll.end())
I'm trying to store pointers to CODBAperture objects that are stored somewhere else in a linked list type of thing. Does (*it) create an instance of CODBAperture?
If your vector only contains pointers to CODBAperture objects? No.
But be aware that keeping pointers to objects in two collections if the one owning the object can delete it during the lifetime of the second referee is obviously inherently dangerous.
|
|
|
|
|
Mike Nordell wrote:
You shall never, I repeat never, compare an iterator to any other iterator than for equality or inequality. Even that a vector is to be contigous, there is AFAIK nothing stating that a vector iterator has to be implemented as a pointer to the contents, why something like:
if (it < coll.end())
is incorrect code. It should be
if (it != coll.end())
Thanks for pointing that out! I didn't notice that one at all.
Mike Nordell wrote:
But be aware that keeping pointers to objects in two collections if the one owning the object can delete it during the lifetime of the second referee is obviously inherently dangerous.
Yes, this was the problem. I was storing a pointer that was no longer valid.
Cathy
Life's uncertain, have dessert first!
|
|
|
|
|
Hi,
Wonder if someone could point me in the right direction, What i want to do is seperate all the User Interface Classes from my processing classes, without using any DLLs.
I envisage doing this through having two projects in my workspace. Does anyone know how i can achieve this. Had a look at Project Wizzard's "Utility Projects", but it doesn't do any build setting to compile.
Cheers
Rich
|
|
|
|
|