|
CDocManager* CDocManager::pStaticDocManager;
CPtrList* CDocManager::pStaticList;
those two member is not in my code ,those in MFC code !
I said that those two member appear memory leak!
BOOL Create() //in ActiveX OnCreate Event perform this function!
{
if( m_pFrameWnd )
{
if( IsWindow(m_pFrameWnd->m_hWnd) ) return TRUE;
}
CSingleDocTemplate * pDocTemplate;
pDocTemplate = new CSingleDocTemplate(IDR_MAPTYPE,
RUNTIME_CLASS(CMapDoc),
RUNTIME_CLASS(CMapFrame),
RUNTIME_CLASS(CMapView));
// pDocTemplate in destructor function delete this!
CMapDoc * pDoc = new CMapDoc;// in destructor function delete this!
CCreateContext Context;
Context.m_pCurrentDoc = pDoc;
Context.m_pNewDocTemplate = pDocTemplate;
Context.m_pNewViewClass = RUNTIME_CLASS(CMapView);
Context.m_pLastView = NULL;
Context.m_pCurrentFrame = NULL;
CMapFrame * pFrameWnd = new CMapFrame;// in destructor function delete this!
m_pDoc = pDoc;
m_pFrameWnd = pFrameWnd;
m_pDocTemplate = pDocTemplate;
CRect rcMap;
GetClientRect(&rcMap);
BOOL ret = m_pFrameWnd->Create(AfxRegisterWndClass(CS_DBLCLKS), NULL, WS_CHILD|WS_VISIBLE, rcMap,this,NULL,&Context);
m_pFrameWnd->ShowWindow(SW_SHOW);
return ret;
}
//note :
CMapDoc inherit from COleDocument ;
CMapView inherit from CScrollView ;
CMainFrame inherit from CFrameWnd ;
I don't have CDocManager and it's derive class!
debug output :
Detected memory leaks!
Dumping objects ->
plex.cpp(31) : {72} normal block at 0x01402F70, 124 bytes long.
Data: < @ > 00 00 00 00 00 00 00 00 00 00 00 00 00 11 40 01
doctempl.cpp(64) : {71} client block at 0x01401060, subtype 0, 32 bytes long.
a CDocManager object at $01401060, 32 bytes long
doctempl.cpp(62) : {70} client block at 0x014010B0, subtype 0, 28 bytes long.
a CPtrList object at $014010B0, 28 bytes long
ZHANGYIFEI
|
|
|
|
|
Open appcore.cpp and look at CWinApp::~CWinApp(), this is where CDocManager::pStaticList and CDocManager::pStaticDocManager are deleted. Since CWinApp is not the base class for your project then these two pointers will not be deleted. Therefore, you must delete them your self. I beleive that the plex.cpp memory leak should go away when you fix the other two, because it is used to allocate storage for nodes and CDocManager uses a list of nodes used to store the docment template pointers.
Note also, that the list of memory leaks is the inverse of the order of allocations.
1) CPtrList is allocated.
2) CDocManager is allocated.
3) CPlex alloction occurs (CDocManager::pStaticList->AddTail(this)).
:-OThanks for the dump, it made the answer ovious where the problem was.
Blast I should have seen this earlier!!!
|
|
|
|
|
I want to Create a Frame/view/doc structure On a ActiveX Control,but It will be Found Memory leak! And I Found that the reasons is :
CDocManager* CDocManager::pStaticDocManager;
CPtrList* CDocManager::pStaticList;
How Can I avoid Memroy leak?
the Following is My Code :
BOOL Create()
{
if( m_pFrameWnd )
{
if( IsWindow(m_pFrameWnd->m_hWnd) ) return TRUE;
}
CSingleDocTemplate * pDocTemplate;
pDocTemplate = new CSingleDocTemplate(IDR_MAPTYPE,
RUNTIME_CLASS(CMapDoc),
RUNTIME_CLASS(CMapFrame),
RUNTIME_CLASS(CMapView));
CMapDoc * pDoc = new CMapDoc;
CCreateContext Context;
Context.m_pCurrentDoc = pDoc;
Context.m_pNewDocTemplate = pDocTemplate;
Context.m_pNewViewClass = RUNTIME_CLASS(CMapView);
Context.m_pLastView = NULL;
Context.m_pCurrentFrame = NULL;
CMapFrame * pFrameWnd = new CMapFrame;
m_pDoc = pDoc;
m_pFrameWnd = pFrameWnd;
m_pDocTemplate = pDocTemplate;
CRect rcMap;
GetClientRect(&rcMap);
BOOL ret = m_pFrameWnd->Create(AfxRegisterWndClass(CS_DBLCLKS), NULL, WS_CHILD|WS_VISIBLE, rcMap,this,NULL,&Context);
m_pFrameWnd->ShowWindow(SW_SHOW);
return ret;
}
ZHANGYIFEI
ZHANGYIFEI
|
|
|
|
|
Hi
I've got a CString text which i got to convert to a char[32]. Any easy solution for this?
Thanks
Jens
|
|
|
|
|
Use this:
CString String = "Hello";<br />
char CharString[32];<br />
strcpy(CharString,String);<br />
CString has an overloaded operator LPCTSTR that automatically converts the CString into a char*!
|
|
|
|
|
Or to be safer use strncpy instead:
<br />
<br />
#define MAXLEN 32;<br />
<br />
CString String = "This could be a very long string and we could get a buffer overrun :)";<br />
char CharString[MAXLEN];<br />
<br />
strncpy(CharString,String,(MAXLEN-1));<br />
<br />
CharString[MAXLEN-1] = '\0'; <br />
<br />
|
|
|
|
|
Read the MSDN point CString operator (LPCSTR) and "strcpy".
Try this @ home. (B&B)
|
|
|
|
|
ok thanks
Do you happen to know if there is a member function who allows to know the previous selection in a CTreeCtrl?
Greetings
Jes
|
|
|
|
|
You get them as the oldItem when handling the TVN_SELCHANGING notification.
There is some info an an example in MSDN about it.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
can any body get me a module or source code of the software FONT CREATOR ... or FONTOGRAPHER ?
or source code similar to these softwares....which would take inputs of all the glyphs from eps files and finally convert them to true type font file.
--plz help me its regarding my job.
thanks
Aakash
|
|
|
|
|
Hi Alvaro
GetTreeCtrl() didn't work for me, i tried it out like this:
CTreeCtrl* pTreeCtrl = (CTreeCtrl*) GetDlgItem(IDC_TREEVIEW);
HTREEITEM hItem = pTreeCtrl->GetSelectedItem();
CString strText = pTreeCtrl->GetItemText(hItem);
I now get the text correctly, thanks
But now, i want to know with which kind of 'level' we are talking about: root, child or 'child of child'.
So i only want to perform some actions on a leaf.
Any1 any idea?
Greetings Jens
Never mind, i have filled for each tvitem structure the lParam with some user-defined data in it.
Greetings
Jens
|
|
|
|
|
Hi.
I just wanna ask if you guys know how to run visual c++ executable files in OS/2? I think the problem is that it's 32-bit, while OS/2 is 16 bit.. Any ideas how to convert visual c++ output to 16-bit??
Thanks
|
|
|
|
|
Hello,
Did anybody tried to store data (example: CString) in a DLL.
I just want to store some of my data in a DLL, and donot want to use any file to store that data.
Somone has ever did this or have any idea how to do this
Regards,
The Phantom
|
|
|
|
|
If I have handle to the window (HWND), how can I get the window title and the application's path using the win32 API functions.
|
|
|
|
|
//vollständigen Pfad ermitteln
char szPfad[ _MAX_PATH ];
VERIFY( ::GetModuleFileName( AfxGetInstanceHandle(), szPfad, _MAX_PATH ) );
Try this @ home. (B&B)
|
|
|
|
|
And for the window title, you can use this:
char Buffer[255];<br />
CWnd* pNewWnd = YourWindow->FromHandle(YourHandle)<br />
pNewXnd->GetWindowText(Buffer,254);
YourWindow is a CWnd (doesn't matter wich one). FromHandle returns the CWnd* attached to the Handle 'YourHandle'!
|
|
|
|
|
This has got to be the most irritating 'feature' of the windows API. not one problem has given me so much trouble, here is how my error catching goes:
[code]
int main(int argc, char ** argv)
{
try
{
CApp Instance;
return Instance.Run();
}
catch(ErrorInfo Error)
{
// build message here
MessageBox(NULL, Message, Title, MB_ICONERROR);
}
return 0;
}
[/code]
it works perfectly up to the .Create method of ATL's CWindowImpl. after that, DestroyWindow gets called, which seems to disable dialogs, which disables the message box. i've debugged it, it goes right over the call without displaying the window, but it does play the sound. is there any way to 'reset' windows before i show the message box?
|
|
|
|
|
Hi all,
can any one explain me what is the difference in the following code.
1.I have a class CSample.
2.I want to create an object on heap by using new operator for CSample.
I found there are two methods for this.
1.One is like this
CSample * pSamep=new CSample;
and
2.second one is like this
typedef auto_ptr<csample> pSample;
pSample(new CSample());
what is the difference with these two methods.which one is more efficient.
thanks in advance.
regards
raju
anju
|
|
|
|
|
anju wrote:
typedef auto_ptr pSample;
I assume you meant: typedef auto_ptr<CSample> pSample;
The auto_ptr is a small structure that holds the pointer to the object, and a flag indicating whether or not it owns the object (it does by default). In it's destructor, it deletes the object if it owns it. This can greatly simplify memory management, as these smart pointers take care of deleting themselves when they go out of scope.
In terms of efficiency, the auto_ptr would be every so slightly less efficient, but we are probably talking literally one or two CPU instructions, so it is really irrelevant.
Dave
http://www.cloudsofheaven.org
|
|
|
|
|
I have tried the follwing :
typedef auto_ptr<cstring> str;
but is not working. Gives error "syntax error : missing ';' before '<'".
Is any header file needed?
Chintan
C.R.Naik
|
|
|
|
|
I think it is in the <memory> header file, but it is also defined within the std namespace.
If you repost your error message, take not that codeproject thinks that everything between angle brackets is an HTML tag, and so does not display it. You should use < and >
Dave
http://www.cloudsofheaven.org
|
|
|
|
|
previous time I have tried :
typedef auto_ptr < CString > str;
and again I have tried the following one :
typedef std::auto_ptr < CString > str;
but both are not working and giving error
Chintan
C.R.Naik
|
|
|
|
|
|
Both are unable to solve the problem.
C.R.Naik
|
|
|
|
|
I thought it might be useful to explain a little
more of the reason why auto_ptr was included in
the standard. (There was a great deal of haggling
about this and other types of pointer wrappers,
and there are a number of other pointer wrappers
in boost (boost.org) that will almost certainly
make it into the next version of the standard.)
The reason why auto_ptr is important relates to
exceptions. Consider this:
class excep { /* some exception class */};
void g()
{
try { f(); }
catch(excep &e)
{ handle(e); }
}
void f()
{
int* a = new int;
*a = might_throw_excep();
other_fn();
delete a;
};
Now consider what happens if might_throw_excep throws
an exception. In that case, the stack unwinds to
the nearest matching catch statement (in g), but that
means that a, which is now out of scope, points to
heap allocated memory that will never be deleted.
auto_ptr solves this problem, by rewriting f() as the
following:
void f()
{
auto_ptr<int> a = new int;
*a = might_throw_excep();
other_fn();
}
In this case, the destructor of a (which is an auto_ptr
template class) is called when it goes out of scope. This
causes the object a to be deleted. However, what is more
important is this: even if might_throw_excep throws, then
as part of the exception processing system, the destructors
of the classes are called as the stack is unwound to the
catch statement. This happens even though other_fn is not
called. That means that, even if an exception is
thrown, a's destructor is called, and it doesn't leak
memory.
For that reason, auto_ptr (or something like it) is
necessary to write leak free code in the presence of
exceptions. This is the motivation, AFAIK, behind why
auto_ptr was added to the standard.
HTH.
|
|
|
|