|
hi friend ,
char szFolderPath[MAX_PATH];
LPBROWSEINFO pBrowseInfo;
pBrowseInfo=new BROWSEINFO ;
pBrowseInfo->hwndOwner=m_hWnd;
pBrowseInfo->pidlRoot=NULL;
pBrowseInfo->pszDisplayName=szFolderPath;
pBrowseInfo->lpszTitle="the text u enter here is appeared in the top of the dialog ";
pBrowseInfo->ulFlags=BIF_RETURNONLYFSDIRS;
pBrowseInfo->lpfn =NULL;
pBrowseInfo->lParam=0;
pBrowseInfo->iImage =0;
LPITEMIDLIST pIdList;
pIdList=SHBrowseForFolder(pBrowseInfo);
SHGetPathFromIDList(pIdList,szFolderPath);
//Now u get the foder path in szFolderPath...
delete pBrowseInfo;
OK???
-Renjith
Trace The Bugs...
|
|
|
|
|
Thank you. 
|
|
|
|
|
I'm getting an "Unhandled exeption" when running this function. I get it when it comes to the pBrowse->Next line. I have already tested if pBrowse is null and it isn't, neihter is pIdl. Here's the code
void OnOpenFolder()
{
BROWSEINFO bi = {0};
IShellFolder *pSf;
LPMALLOC pMalloc;
DWORD pActual = 0;
bi.hwndOwner = ghWnd;
bi.pidlRoot = NULL;
bi.lpszTitle = "Locate MP3 Folder";
bi.ulFlags = BIF_DONTGOBELOWDOMAIN;
bi.lpfn = NULL;
SHGetDesktopFolder (&pSf);
if (pSf)
{
LPITEMIDLIST pIdl;
pIdl = SHBrowseForFolder(&bi);
if (pIdl)
{
IEnumIDList *pBrowse;
SHGetMalloc(&pMalloc);
pSf->BindToObject(pIdl, NULL, IID_IShellFolder, (LPVOID*)&pBrowse);
pBrowse->AddRef();
if (pBrowse)
{
while (pBrowse->Next(1, &pIdl, &pActual) == S_OK)
{
LVITEM Lvi = {0};
char szPath[MAX_PATH+1];
SHGetPathFromIDList(pIdl, szPath);
Lvi.mask = LVIF_TEXT;
Lvi.pszText = szPath;
Lvi.iItem = SendMessage(DlgItems[7], LVM_GETITEMCOUNT, 0, 0);
ListView_InsertItem(DlgItems[7], &Lvi);
}
}
pBrowse->Release();
}
pMalloc->Free(pIdl);
pMalloc->Release();
}
pSf->Release();
}
ghWnd is the hanlde to my window (yes, it's valid)
DlgItems[7] is the handle to a listview control, also valid.
Here's the exact error: "Unhandled exeption in app.exe (SHELL32.DLL): 0xC0000005: Access Violation."
Any help greatly appreciated
Thanks.
|
|
|
|
|
Just a clue:
There are some mistakes in your code. For example you have:
if(pBrowe)
{
...
...
}
pBrowse->Release();
Where as it should be:
if(pBrowse)
{
...
pBrowse->Release();
}
|
|
|
|
|
pSf->BindToObject(pIdl, NULL, IID_IShellFolder, (LPVOID*)&pBrowse); Shouldn't you be asking for a IID_IEnumIDList?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
void OnOpenFolder()
{
BROWSEINFO bi = {0};
IShellFolder *pSf;
LPMALLOC pMalloc;
LPENUMIDLIST pFolder = NULL;
DWORD pActual = 0;
LVITEM Lvi = {0};
char szFolderPath[MAX_PATH+1];
bi.hwndOwner = ghWnd;
bi.pidlRoot = NULL;
bi.lpszTitle = "Locate MP3 Folder";
bi.ulFlags = BIF_DONTGOBELOWDOMAIN;
bi.lpfn = NULL;
SHGetDesktopFolder (&pSf);
if (pSf)
{
LPITEMIDLIST pIdl;
pIdl = SHBrowseForFolder(&bi);
SHGetPathFromIDList(pIdl, szFolderPath);
Lvi.mask = LVIF_TEXT;
Lvi.pszText = szFolderPath;
Lvi.iItem = SendMessage(DlgItems[7], LVM_GETITEMCOUNT, 0, 0);
ListView_InsertItem(DlgItems[7], &Lvi);
if (pIdl)
{
IShellFolder *pBrowse = NULL;
SHGetMalloc(&pMalloc);
pSf->BindToObject(pIdl, NULL, IID_IEnumIDList, (LPVOID*)&pBrowse);
pSf->Release();
pBrowse->EnumObjects(NULL, SHCONTF_FOLDERS | SHCONTF_NONFOLDERS | SHCONTF_INCLUDEHIDDEN, &pFolder);
if (pBrowse)
{
while (pFolder->Next(1, &pIdl, &pActual) == S_OK)
{
SHGetPathFromIDList(pIdl, szFolderPath);
Lvi.pszText = szFolderPath;
Lvi.iItem = SendMessage(DlgItems[7], LVM_GETITEMCOUNT, 0, 0);
ListView_InsertItem(DlgItems[7], &Lvi);
}
}
pBrowse->Release();
}
pMalloc->Free(pIdl);
pMalloc->Release();
}
pSf->Release();
}
Although there still is a problem. The SHGetPathFromIDList(pIdl, szFolderPath); sets the szFolderPath to <desktop folder="">\<one of="" the="" subfolders="" in="" folder="" i="" chose="" via="" shbrowseforfolder="">
Thanks
|
|
|
|
|
I might be totally wrong, but I think there's still a mismatch problem: if pBrowse is now an IShellFolder *, you should retrieve it using IID_IShellFolder; if you make it a IEnumIDList *, use IID_IEnumIDList. Just keep types straight.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I spoke to soon and thought that deleting the .clw file cleared up my problems with going into the wizzard.
If it isn't in the .clw file where is this error coming from? how do I clear it up.
Thanks again.
|
|
|
|
|
if you have added any code to the AFX_DATA_MAP section of a DoDataExchange, or if you've changed AFX_DATA_INIT in a window constructor, you may have added something that the classwizard doesn't understand.
so, if you have done any of that, try moving your code outside the AFX_DATA_INIT or AFX_DATA_MAP blocks.
-c
ABSURDITY:
A statement or belief manifestly inconsistent with one's own opinion.
|
|
|
|
|
manually editing wizard code causes parsing problems.specially with the classwizard .
|
|
|
|
|
Chris, Right on! That put me in the right place where I found a ; with no code around it.
Thanks.
|
|
|
|
|
Hi,
how to detect the main (primary) thread out of several threads without the toolhelp functions from Win9X respective Win2K, and without MFC's AfxGetMainThread ?
Thanks in advance
|
|
|
|
|
The easiest way is to save the ThreadID in a global before you create the other threads.
Good luck,
Bill
|
|
|
|
|
Recapping the situation: I have an app compiled for Debug which while running under the debugger is fine. If I execute the same app stand-alone it appears to have a memory leak. As suggested earlier, the stand-alone platform was configured for remote debugging.
Under Debug, Task Manager reports the application using around 7MB of memory. Task Manager also reports the overall memory usage of the system to be around 110MB. While the app memory usage varies more than I would have expected, it has not gone over 10MB that I have observed while running in debug mode.
Running standalone Task Manager initially reports the application using the same 7MB amount of memory. After 8 hours of operation the memory usage of the application has increased around to around 10MB, and after 48 hours it is around 14MB. The overall memory usage reported after 8 hours though has increased by 30MB! and this value continues to increase linearly with time. After 48 hours the overall memory usage has exceeded 300MB.
I have placed memory leak detection code around the entire app and inside the app around the core functions. The inside code reports an occassional change in memory, but reports a reciprocal change later on. As noted, it doesn't leak under debug, so dumping statistics to the debug output window is not helping resolve the problem.
Any further suggestions for locating the cause of this problem would be appreciated. FYI, the stand-alone platform is XP though I do not know if this is significant.
>>>-----> MikeO
|
|
|
|
|
Do your app have an UI? Then you might also want to check for GDI or USER handle leaks in your drawing code (using e.g. perfmon or task manager). It wouldn't be the first time handles were left unreleased from a WM_TIMER or WM_PAINT.
|
|
|
|
|
From Task Manager there is already an indication that memory is being consumed, so any suggestions what should be monitored by PerfMon? I've been studying the options this morning. None of them look promising.
Is there something else in Task Manager to check? For instance, when looking at the process list I see the app is using more memory than before, but not nearly as much more as the overall change in memory. The last time I stopped the stand-alone app, Task Manager also showed memory being released gradually instead of all at once. What do these symptoms indicate?
Details if you're interested:
The UI is very simple. Text is either output to a CListBox of limited size which is displayed by the View, or the status bar text is changed. Every few hours the window's caption is changed.
Once every 12 hours a second process is launched which takes about 30 minutes to complete. During this process is the only period when there are multiple timers running.
>>>-----> MikeO
|
|
|
|
|
Mike Osbahr wrote:
when looking at the process list I see the app is using more memory than before, but not nearly as much more as the overall change in memory.
Then it's a handle leak.
Mike Osbahr wrote:
The last time I stopped the stand-alone app, Task Manager also showed memory being released gradually instead of all at once. What do these symptoms indicate?
That you have a lot (a lot) of objects that gets cleaned up at destruction. Are you putting some objects in some container?
Once every 12 hours a second process is launched which takes about 30 minutes to complete. During this process is the only period when there are multiple timers running.
Are your app launching this process? Is it using CreateProcess? You are closing both the process and the thread handle?
|
|
|
|
|
Hi Friend
I am sure you allocate some memeory within your program and u forget to release them properly..so the program allocated memory when it runs...take a close look upon you code..lile new and malloc() or such functions.find it out..!!!
oK??
Trace The Bugs...
|
|
|
|
|
R_Renjith wrote:
I am sure you allocate some memeory within your program and u forget to release them properly..so the program allocated memory when it runs...take a close look upon you code..lile new and malloc() or such
These were the first things that crossed my mind also. I avoid malloc() whenever possible and in this particular app do not use it at all. Every new has a matching delete, though it may be possible that a delete is not being executed.
These types of leaks though usually show up in the output window of the debugger when you terminate. The functions I am using which bother me are GetStringSetBuffer() and ReleaseBuffer(). All of my debug tests indicate they are working properly, but they do allocate and deallocate memory. Any reason to suspect when running stand-alone these behave differently?
>>>-----> MikeO
|
|
|
|
|
From what you have described I have two ideas that might help you.
Check which optimizations you have enabled for the release build. Are you using MinSize or MaxSpeed? If I remember correctly there are a few nasty little bugs waiting to bite you if MinSize is selected. I have run into one before and the result was something similar to your problem.
One other thing that I have run into is a problem with loading DLL libraries dynamically (ala LoadLibrary/LoadLibraryEx). Make sure you are freeing the libraries in an approriate place. I had a situation where memory was being allocated in a DLL but not released before calling FreeLibrary. On Win9? this would leave the DLL in memory.
You might want to disable one at a time and see if you can uncover the problem.
|
|
|
|
|
For now, I am testing running the Debug build stand-alone. Are there any drawbacks to this? It was my understanding that TRACE messages just get dumped when there is no output window available. Other than that, I cannot think of anything in the program that might use memory differently in stand-alone.
>>>-----> MikeO
|
|
|
|
|
There are several problems with this approach.
1) You can't redistribute the debug libraries (MS license)
2) Performance will be much degrade. Amount of performance cost depends on what your program does.
3) ASSERT and VERIFY code is still being executed which can interfere with operation (especially when app is not monitored by a user.) This shouldn't really be too much of an issue if the code has been tested well.
|
|
|
|
|
The points you make about Debug vs. Release code are all valid. My question was with regard to the memory problem. Is there anything in a Debug release that will consume memory while running stand-alone?
The optimization headaches will come later. 
>>>-----> MikeO
|
|
|
|
|
Off the top of my head:
When you build an application with a debug build, the compiler inserts "dog tags" (small areas of memory used to verify the integrity of memory) around your memory and data structures and at runtime these dog-tags are pre-initizliaed with specific values. Then at runtime these dog-tag values are checked against the pre-initialized values. If they differ, you have overrun your memory. This obviously takes more memory depending on the size of your program. Also, MFC maintains a set of handle tables in memory and if I remember correctly, the debug build of MFC can produce very large handle tables. I think it delays the removal of handles from the table so that they can be checked against valid ones later.
When you stay "stand-alone" I assume you mean seperate from the IDE. As far as I know the only difference between a debug build running outside the IDE and one run through the debugger is the prescense of a debug machine which theoritically should not have any impact on your program.
|
|
|
|
|
Someone mentioned something that reminded me of something.
Are you executing any code in an ASSERT or TRACE. If so, this might need to be changed. The code inside of an ASSERT or TRACE isn't execute in release mode.
So things like:
ASSERT (SUCCEEDED (::CoTaskMemFree (pData)));
Wouldn't deallocate the memory in release mode.
The VERIFY macro does execute in release mode.
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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
