|
Here is one way to do this -
Use EnumProcesses to enumerate all running processes.
For each process id returned, call GetProcessImageFileName to check if it belongs to explorer.exe
You will need to do OpenProcess on the process id to get its handle.
After you get the process id of explorer.exe, enumerate all open windows using EnumWindows.
For each window handle returned, use it in the function GetWindowThreadProcessId to check if it belongs to explorer.exe
This process of finding open explorer.exe windows could be time consuming.
Another way to do this would be to write a Browser Helper Object (BHO) which explorer.exe windows will load on startup.
In the BHO you can keep track of open explorer windows and more.
Here is some more information on BHOs - Browser Helper Objects: The Browser the Way You Want It[^]
Here is how to build a BHO using Visual Studio - Building Browser Helper Objects with Visual Studio 2005[^]
|
|
|
|
|
|
Hi,
You could create a ShellWindows object[^] and call get_Count();
Something like this:
INT GetExplorerCount()
{
LONG lCount = 0;
IShellWindowsPtr shell;
shell.CreateInstance(__uuidof(ShellWindows));
shell->get_Count(&lCount);
return lCount;
}
Don't forget to CoInitialize. Also keep in mind that Internet Explorer and Windows Explorer are integrated... you will need to add some code to filter out instances of IE. Control panel windows are also shell windows.
Best Wishes,
-David Delaune
|
|
|
|
|
I have dll where I am creating a dialog whihc is shown from the mfc client application. I loading this dll as an extension dll, then by implementing Do.Modal() function I am showing the dialog which has menus, toolbars,black model visualization screen. When trying to display this screen, it's crashing as debug ASSERT failed, at appcore.cpp
ASSERT(AfeGetThread()==NULL)
My App class is like this in the header file I have the App constructor and in .cpp file I have the construcor and also one instance of ViewApp as below
//MyViewApp.h
[code]
//Inside the class definition
MyViewApp(); //constructor dclaration
//outside the class definition
extern MyViewApp theApp;
[/code]
//MyViewApp.cpp
[code]
MyViewApp::MyViewApp()
{
}
MyViewApp theApp;
[/code]
It's crashing with this code (ASSERT failure in appcore.cpp), and when I am removing this constructor declaration and definition and also removing the one instantiation, then it's not crashing but coming out of the application, My Dialog GUI is not launching.
Please help me whats going wrong in this. Thanks a lot for help in advance.
|
|
|
|
|
My guess would be that you already have a CWinApp derivate instantiated while CWinApp (and so your MyViewApp since it is also a derivate of CWinApp) expects to be the one and only. Sad that in wincore.cpp there seems to be no comment whatsoever around those ASSERT-s to give you some additional information about what's wrong.
I suspect that you have MyViewApp inside the DLL and you are loading it into your application which already has a CWinApp derivate. If so, you should try displaying and handling your dialog in the "context of the original application".
Could this be it?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
how can I do that please give me some hint..
I have one api exposed for mfc client called 'runAppli'
[code]
__declspec(dllexport)runAppli(CString fileName)
{
CDlgsViewDlg dlg(fileName, NULL);
dlg.DoModal();
return true;
}
[/code]
Using this I am calling the dll after loading.
So how can I
displaying and handling your dialog in the "context of the original application".
Please give me some hints.
|
|
|
|
|
Hard to say without seeing the whole picture, but...
Am i right that you have an application class instantiated in both the DLL and the app that loads it? If yes, do you need an application class inside the DLL? If yes, why? If no, try to get rid of it and see if it helps.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
sujandasmahapatra wrote: It's crashing with this code (ASSERT failure in appcore.cpp)
appcore.cpp is a big place! Whenever you ask for help and say an ASSERT is failing for the love of god paste in the code around the ASSERT statement.
Steve
|
|
|
|
|
Is there any tool which can tell types of control is being used by runing software?
|
|
|
|
|
Not completely sure what you mean but try Spy++, it comes with Visual Studio, you can use it to find out what class windows/controls on windows have.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
|
I made a tool window, and then made a treeview, with the tool window being the parent.
I also have a class, that populates the treeview with folder contents.
How do I access the treeview, to populate it?. What I mean is when I make the treeview in the main window, I can just call the HWND to connect to it, but when the treeview is a child of the tool window, I can't access it.
My goal is to have the treeview a child of the tool window, so they always stay together.
I had trouble creating the tool window successfully for awhile, and then I moved the code below to the main window cpp page. The tool window has it's own WndProc.
tbProjectExplorer = CreateWindowEx(
WS_EX_TOOLWINDOW,
szProjectExplorer_Class,
TEXT( "Project Explorer" ),
WS_POPUP | WS_SYSMENU | WS_THICKFRAME | WS_CAPTION | WS_VISIBLE,
winWidth - tvWidth, 1,
tvWidth, tvHeight,
hWnd,
NULL,
GetModuleHandle(0),
NULL
);
ShowWindow( tbProjectExplorer, SW_SHOW);
tvProjectExplorer = CreateWindowEx(
WS_EX_TRANSPARENT,
WC_TREEVIEW,
TEXT( "Project Explorer" ),
WS_VISIBLE | WS_CHILD | WS_BORDER | TVS_DISABLEDRAGDROP | TVS_TRACKSELECT | TVS_HASBUTTONS | TVS_EDITLABELS | TVS_SHOWSELALWAYS | TVS_SINGLEEXPAND,
0, 0,
tvWidth, tvHeight,
tbProjectExplorer,
(HMENU) IDM_PROJECT_EXPLORER,
GetModuleHandle(NULL),
NULL
);
SendMessage( tvProjectExplorer, WM_SETFONT, (WPARAM) hFont_lbl, FALSE);
ShowWindow( tvProjectExplorer, SW_SHOW);
|
|
|
|
|
I'm going to scape this idea and try something else.
|
|
|
|
|
For what it's worth, the way to achieve this task is to populate the TreeView inside the WindowProc for the tool window.
Just handle the WM_CREATE message of the tool window, then:
- create the treeView
- populate it
|
|
|
|
|
Thanks
I moved the WndProc for the Toolbar Popup, and the Treeview CreateWindow to the Class that populates the Treeview with Folder Contents in a new function. So now I just make the window, position it, and then create the treeview on the fly when loading the folder contents.
Sort of confusing of how it works, but I get it now.
Thanks for giving me the low down on it, was getting frustrated with it.
|
|
|
|
|
I'm not exactly sure what I was expecting with this, but when multi-column sorting is enabled, I do not see anything special happening with the virtual OnCompareItems() function. When I click the first column, that function is called the appropriate number of times, with iColumn set to the index of the column I clicked. All items are sorted fine. When I shift-click the second column, again that function is called the appropriate number of times, with iColumn set to the index of the second column I clicked (i.e., no mention of the first column). Both of the columns I clicked have a "sort" arrow in its header, however.
Any ideas?
Thanks.
- DC
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
So, I had memory leaks and I was helped by a benevolent programmer (Chuck...) and kicked to the ground by another (Richard...); both of which helped me solve the problem.
Now that we/I solved the memory leaks in my program, is there anything I need to do since I ran the program forever not knowing there were leaks?
|
|
|
|
|
Member 7990715 wrote: ...is there anything I need to do since I ran the program forever not knowing there were leaks?
Wouldn't you be in a better position to know what needs to be done to your program? 
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
My program now has no memory leaks. I thought since there were memory leaks for a while, the memory on my computer might need attention; l; like go delete the huge amounts of variables I left un-deleted.
No?
Are you saying once I fix my program from memory leaks that there are no lasting problems with the computer?
|
|
|
|
|
assertfailed wrote: I thought since there were memory leaks for a while, the memory on my computer might need attention;
Not if your program has since been shut down.
assertfailed wrote: Are you saying once I fix my program from memory leaks that there are no lasting problems with the computer?
That is correct.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
|
The memory that "leaked" is the address space of the program you are running. What happens to long running programs is that they lose track, i.e. leak, allocated memory so they grow over time, eventually running out of memory (virtual address space). At that time, malloc(), new, or other such calls that request more memory fail and the program will probably start misbehaving.
However, when you stop the program, kill it with task manager, click the big "X" to close the window, or other such ways to stop programs in Windows (or Linux or whatever), the program is removed from physical memory and all that "lost" memory is given back.
The Operating System (Windows, Linux, etc) never really loses track of the memory, only the program running does. All is recovered when the program dies (in natural or unnatural ways).
Back in the '60s, we used to say that certain operations (like right or left shifts) dropped the discarded bits in the "bit bucket". We'd tell Computer Science 1 students that the bit bucket needed to be periodically emptied  Same thing here, we don't need to go back and mop up the leaks 
|
|
|
|
|
|
you should go have a beer. your work is done!
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
