|
Did post it there last night, about the same time I posted here. Haven't got an answer there yet.
Adam Clauss
cabadam@tamu.edu
|
|
|
|
|
Yup, you have hit an internal bug in the linker. Try a rebuild all.
That MSPDB70.DLL is probably a common DLL they use to support the .PDB debug files.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Did a full rebuild, made no difference. Still fails in the linking 
Adam Clauss
cabadam@tamu.edu
|
|
|
|
|
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  ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
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!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
