C / C++ / MFC

22-May-02 3:24

First I would like to thank all of you who have made suggestions about this problem you've been a big help. Second I apologize if reposting a topic is considered bad form, but its difficult to find a thread after a couple of days on this forum.

This problem is more bizarre than I had originally thought. As stated before, if the app is run in debug its fine. If the debug .EXE runs outside of debug the app memory usage appears to grow linearly with time. The release .EXE, which I have now built and tested, does the same thing.

Now I've found a new twist...

Following a suggestion from Mike Nordell, I was setting up PerfMon this morning to look at exactly how memory was being used. Unexpectedly while doing this the memory used by the app dropped from 27MB to 17MB. After watching PerfMon for several minutes and wondering about the memory drop I decided to minimize the app then restore it. The memory again dropped. This time to about the original starting value.

If this is a destructor issue how does a minimize/restore change things? Does debug perform some type of clean-up that the OS waits for user interaction to trigger? This isn't Java and I wrote the app to take care of itself, so what gives?

>>>-----> MikeO

Tim Smith22-May-02 5:00

Tim Smith

22-May-02 5:00

You are looking at the working set size and not the real virtual memory size.

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?

Mike Osbahr22-May-02 5:54

22-May-02 5:54

Wasn't sure what you meant at first. Confused | :confused:

Went back and looked at the overall memory usage and it is still high. Frown | :(

So, if it is objects not being released, why does the overall memory usage remain low when debugging remotely?

>>>-----> MikeO

Tim Smith22-May-02 7:39

Tim Smith

22-May-02 7:39

There is always the chance that due to bugs in your software memory is getting freed in debug build and not in release. The usual cause of this is uninitialized variables in routines. Another cause if writing past the end of allocated memory.

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?

Mike Osbahr22-May-02 9:39

22-May-02 9:39

Any known memory issues with maps in the MS STL library?

>>>-----> MikeO

Mike Nordell23-May-02 3:48

Mike Nordell

23-May-02 3:48

I think so. Check the updates at Dinkumware. IIRC it's at
http://www.dinkumware.com/vc_fixes.html

Regarding the memory drop when minimizing: As already pointed out it's the working set that drops. The reason for this is that every time you minimize an application, Windows does what in effect is like calling SetProcessWorkingSetSize(GetCurrentProcess(), -1, -1); from within the app itself.

CDialog

Zizilamoroso22-May-02 3:06

Zizilamoroso

22-May-02 3:06

Easy question, this is.

I want to start a function after a CDialog appears on the screen, after the initialisation and paint functions that is. What message do I use, or which function do I deprecate?

It's a bit like the windowOpened(WindowEvent e) java-equivalent.

I've tried several functions and messages (like WM_SHOWWINDOW), but they all appeared before the dialog showed up.

[VISUAL STUDIO 6.0] [MFC] [WIN98/2]

Bluute tette! Dead | X|

Martin Ziacek22-May-02 3:29

Martin Ziacek

22-May-02 3:29

Try to handle first occurence of WM_ENTERIDLE message. It should be sent after your dialog had been displayed.

Martin

Zizilamoroso22-May-02 3:28

Zizilamoroso

22-May-02 3:28

How can I change the CDialog message filter to a message filter for Window? Because ENTERIDLE is a Window-message, not a CDialog-message.

[VISUAL STUDIO 6.0] [MFC] [WIN98/2]

Bluute tette! Dead | X|

Zizilamoroso22-May-02 3:29

Zizilamoroso

22-May-02 3:29

Oeps, too hasty. Forgot the clw. Never mind.

[VISUAL STUDIO 6.0] [MFC] [WIN98/2]

Bluute tette! Dead | X|

Martin Ziacek22-May-02 3:47

Martin Ziacek

22-May-02 3:47

I am sorry, I did not realise, WM_ENTRIDLE does not work in CDialog, and you cannot use. Instead of that, you can use WM_KICKIDLE:

1. Include #include <afxpriv.h> to your dialog cpp file.
2. add ON_MESSAGE(WM_KICKIDLE, OnKickIdle) to your message map
3. add function LRESULT OnKickIdle(WPARAM, LPARAM lCount); to your dialog.

It will work in the same way as WM_ENTRIDLE.

Martin

Nish Nishant22-May-02 3:31

Nish Nishant

22-May-02 3:31

PostMessage(WM_USER+1) from OnInitDialog()
Now in the handler for WM_USER+1, you can do your stuff.
You'll have to add the message macros manually.

Nish

Regards,
Nish
Native CPian.
Born and brought up on CP.
With the CP blood in him.

FindNextFile() ???

GoLa22-May-02 3:07

GoLa

22-May-02 3:07

I Need to get the file size of a file,
Anyone ho now??? Confused | :confused:

\GoLa

KarstenK22-May-02 3:14

KarstenK

22-May-02 3:14

Look at CFileStatus.

GoLa22-May-02 3:17

GoLa

22-May-02 3:17

Thanks but I need to use FindNextFile do you now how???

\GoLa

Mike Osbahr22-May-02 3:39

22-May-02 3:39

Like this?

int Size;
CFileFind finder;
CString FileType("*.TYP");
while (BOOL Found = finder.FindFile(FileType)) {
Found = finder.FindNextFile();
if (Found) Size = finder.GetLength();
}

>>>-----> MikeO

Carlos Antollini22-May-02 3:52

22-May-02 3:52

Is better in that mode:

int Size;
CFileFind finder;
CString FileType("*.TYP");
finder.FindFile(FileType)
while(Found)
{
  Found = finder.FindNextFile();
  Size = finder.GetLength();
}

Olways when you need to know any propiertie of a file that you found, you need to do FindNextFind

Best Regrds

Carlos Antollini.
www.wanakostudios.com
Sonork ID 100.10529 cantollini

Mike Osbahr22-May-02 4:27

22-May-02 4:27

Carlos Antollini wrote:

int Size;
CFileFind finder;
CString FileType("*.TYP");
finder.FindFile(FileType)
while(Found)
{  
  Found = finder.FindNextFile();
  Size = finder.GetLength();
}

Hi Carlos,
Looking things over I think we both left some issues dangling. Let me try one more time:

BOOL Found;
CFileFind finder;
CString FileType("*.TYP");
Found = finder.FindFile(FileType)
while(Found)
{  
  Found = finder.FindNextFile();
  Size = finder.GetLength();
}

When Found changes to false is finder still valid? I can never remember exactly how that works.

>>>-----> MikeO

Carlos Antollini22-May-02 4:42

22-May-02 4:42

Mike Osbahr wrote:
When Found changes to false is finder still valid? I can never remember exactly how that works.

Yes is true...
When you need to ask about any property of the file that you found, like name, size, extension, attributes, you before must to do FindNextFile. You dont must worry about the result of FindNextFile...

For example in the MSDN read the Remarks section of CFileFind::GetFilePath,

Regards

Carlos Antollini.
www.wanakostudios.com
Sonork ID 100.10529 cantollini

ISEffects - effects for images

C^hris L^osinger22-May-02 3:54

C^hris L^osinger

22-May-02 3:54

from http://www.codeproject.com/file/sadirread.asp

WIN32_FIND_DATA FindFileData;
HANDLE hFind;
if ((hFind = FindFirstFile(fullPath, &FindFileData))!=INVALID_HANDLE_VALUE)
{
    // we only care about files, not subdirs
    if ((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)!=FILE_ATTRIBUTE_DIRECTORY) 
     {
        size = ((unsigned __int64)FindFileData.nFileSizeHigh * ((unsigned __int64)MAXDWORD+1)) + (unsigned __int64)FindFileData.nFileSizeLow;
     }
}

and, of course the FindNextFile loop comes right below this.

-c

Cheap oil. It's worth it!

Carlos Antollini22-May-02 4:27

22-May-02 4:27

Is the Following better?

int nSize;
CFileFind finder;
CString FileType("*.TYP");
finder.FindFile(FileType)
while(Found)
{
  Found = finder.FindNextFile();
  if(finder.IsDots() || finder.IsDirectory())
    continue;
  nSize = finder.GetLength();
}

Cheers

Carlos Antollini.
www.wanakostudios.com
Sonork ID 100.10529 cantollini

ISEffects - effects for images

C^hris L^osinger22-May-02 4:39

C^hris L^osinger

22-May-02 4:39

not if the original poster wants to use FindNextFile, not CFileFinder.

-c

Cheap oil. It's worth it!

Carlos Antollini22-May-02 4:45