C / C++ / MFC

6-Apr-11 4:00

CFormView::OnClose() is not called because views do not have a close button. The close button belongs to the frame window, and OnClose() is a message handler for it.

You could call something in the view from your frame window OnClose(), or add a message handler in the view for WM_DESTROY (OnDestroy()).

Best wishes,
Hans

how to use visual leak detector

Re: FormView on close

Sakhalean6-Apr-11 4:09

Sakhalean

6-Apr-11 4:09

yes thank you.
I have to call OnClose() of View's frame.

shashankacharya6-Apr-11 1:10

6-Apr-11 1:10

Can any one tell me that how to use visual leak detector.???
I am using visual studio 2003.
Thank u in advance.

Hans Dietrich6-Apr-11 1:18

6-Apr-11 1:18

The article for VLD is here: Visual Leak Detector - Enhanced Memory Leak Detection for Visual C++[^]

If you have questions about it, the best place to ask is on the article forum.

Best wishes,
Hans

shashankacharya6-Apr-11 1:30

6-Apr-11 1:30

Thanx hans
It was very good articles.
But in my Output window I got
No memory leaks detected.
Visual Leak Detector is now exiting.
Detected memory leaks!
Dumping objects ->
{379552} normal block at 0x12F15B10, 102 bytes long.
Data: < C|& * > B8 AE 43 7C 26 00 00 00 2A 00 00 00 01 00 00 00
{379550} normal block at 0x02327DB8, 102 bytes long.
Data: < C| * > B8 AE 43 7C 1F 00 00 00 2A 00 00 00 01 00 00 00
{339020} normal block at 0x02328150, 118 bytes long.
Data: <D : \ Myapp> 44 00 3A 00 5C 00 51 00 50 00 6C 00 75 00 73 00
Object dump complete.

Pravin Patil, Mumbai6-Apr-11 1:18

Pravin Patil, Mumbai

6-Apr-11 1:18

You can find a good link at Visual Leak Detector - Enhanced Memory Leak Detection for Visual C++[^]

Hope this helps.
All the best.

shashankacharya6-Apr-11 17:07

Memory leak during termination of thread

6-Apr-11 17:07

thanx pravin it was nice article

shashankacharya5-Apr-11 23:51

5-Apr-11 23:51

Helllo everybody
plz help me ... I started one thread in my application in mfc but on close of my view I got memory leak
{367668} normal block at 0x021D82F0, 102 bytes long.
Data: < C|& * > B8 AE 43 7C 26 00 00 00 2A 00 00 00 01 00 00 00
{367666} normal block at 0x121BA1E0, 102 bytes long.
Data: < C| * > B8 AE 43 7C 1F 00 00 00 2A 00 00 00 01 00 00 00
{342539} normal block at 0x02219868, 118 bytes long.
Data: <D : \ MyApp > 44 00 3A 00 5C 00 51 00 50 00 6C 00 75 00 73 00
{254649} normal block at 0x1216AA18, 70 bytes long.
Data: < C| > B8 AE 43 7C 1A 00 00 00 1A 00 00 00 01 00 00 00
{188285} normal block at 0x02259E90, 70 bytes long.
Data: < C| > B8 AE 43 7C 1A 00 00 00 1A 00 00 00 01 00 00 00
Object dump complete.
This errors got. please help me
In on close methode
SetEvent(m_hKillThread);
::TerminateThread (m_Thread->m_hThread,1);
WaitForSingleObject (m_Thread->m_hThread,INFINITE);
m_Thread->Delete ();
CloseHandle (m_hKillThread);
Plz help me Confused | :confused:

Cedric Moonen6-Apr-11 0:07

Cedric Moonen

6-Apr-11 0:07

shashankacharya wrote:
::TerminateThread (m_Thread->m_hThread,1);

Never use TerminateThread, this is a very bad approach. I suggest you read this article[^] from which you will learn a lot for threads. This is a long article but it's definitively worth reading it.

Cédric Moonen
Software developer

Charting control [v3.0]
OpenGL game tutorial in C++

shashankacharya6-Apr-11 0:19

6-Apr-11 0:19

Thanx Cedric
Before using terminatethread, I used same logic which given into link but at that time I got run time exception on delete Cwin thread..
is there having another way to remove memory leak....
Can vld find out memory leak which occures due to thread termination.
Thank You For your reply...

heliboy6-Apr-11 0:16

heliboy

6-Apr-11 0:16

First, do not use TerminateThread() to forcely terminate thread. The best way is let the thread terminate itself. If you want to terminate thread while thread is running, set a flag to notify the thread and let it self-terminate. Read the book "Multithreading Applications in Win32", a good book you need to read before you use multithread.

Second, you need to check your code to see where you dynamic created variable but not delete it upon thread exit. You need to check this yourself, no other people can help you.

shashankacharya6-Apr-11 0:24

6-Apr-11 0:24

Thanx for your reply... I will read that book.
And in my thread I just used local Variable, mydoc variable and my view variables...

Albert Holguin6-Apr-11 17:19

Albert Holguin

6-Apr-11 17:19

even if you use local variables you'll end up with memory leaks if the thread is not properly shutdown... good luck! Smile | :)

shashankacharya6-Apr-11 22:16

6-Apr-11 22:16

thanx albert

Conflicting Resource IDs

softwaremonkey5-Apr-11 20:32

softwaremonkey

5-Apr-11 20:32

Hi,

I am linking my app with a number of static libraries which contain dialog resources etc. Unfortuntately, some of the resource IDs appear to be conflicting. I could reallocate the resource IDs in the static libs to overcome this but is there a better way?

Thanks

Tony

Hans Dietrich5-Apr-11 22:24

5-Apr-11 22:24

The only IDs that must be unique are dialog IDDs, string IDSs, and menu IDs. The IDCs can be reused (between dialogs) and it won't matter.

To ensure that the dialog IDDs don't collide, you could switch to string resource names, instead of numeric resource IDs. To do this, simply comment out the IDD define in resource.h, and change the ctor of the dialog to use the string form. Also comment out the enum in the dialog header file.

Ideally, the resource.h file should be organized by dialog, so that each IDC is unique; sometimes this can get away from you. You might want to check into the excellent Resource ID Organiser Add-In for Visual C++ 5.0/6.0/.NET[^] as a way of restoring order to resource.h.

Best wishes,
Hans

softwaremonkey6-Apr-11 0:33

softwaremonkey

6-Apr-11 0:33

Hi Hans,

Thanks for the reply - that's a great idea!

Thanks again Thumbs Up | :thumbsup:

Tony

softwaremonkey6-Apr-11 10:17

softwaremonkey

6-Apr-11 10:17

Hans,

Sorry to trouble you again but I have changed the dialogs to use string resources and recompiled both the lib and the application which uses the lib. Everthing compiled OK but the dialog does not appear when DoModal() is called. I have trace through the MFC code for DoModal() and the call to FindResource() returns NULL, even though the resource name is correct.

If I compile the library as a DLL then the dialog appears OK.

I realise its hard to do things by remote control but do you have any thoughts as to what could be causing this problem, or what I could check?

Confused | :confused:

Thanks

Tony

Hans Dietrich6-Apr-11 16:13

6-Apr-11 16:13

In your original message you said "I am linking my app with a number of static libraries which contain dialog resources". This is not possible. A static lib cannot have resources. A DLL (really an exe) can contain resources.

Best wishes,
Hans