T
Tim Chase
I have found that EnumWindows works very quickly. In DotNet (I use
C#), I can enumerate the windows, narrow them down to just the windows
which are the main windows (i.e., windows which you can alt-tab to),
identify the associated executables, group by executable, sort the
executables alphabetically, then sort the main windows alphabetically
once they have been grouped by executables, and have this done without
the user noticing any delay when the entire process is initiated each
time by clicking on a menu. The process fills the menu with menuitems
(the executables) then sub-menuitems (the main windows). However,
there is a fairly appreciable delay when enumerating all processes and
their modules (including the dll modules), then representing the
information in treeview.
The differences? When performing working with the windows, I am using
p/invoke (i.e., static intern) to call Win32 api functions rather than
the DotNet api, representing a great deal less data (although the
amount of data I am making use of may be at least as great), and using
a menu rather than a treeview. I am beginning to think that greater
use of the ability to intelligently set the capacity could speed
things up (with respect to the treeview), but I am also beginning to
the that greater emphasis needs to be placed by the developers of
DotNet on the optimization of their api, at least within certain parts
of System.Diagnostics. Has anyone had similiar (or different)
experiences?
C#), I can enumerate the windows, narrow them down to just the windows
which are the main windows (i.e., windows which you can alt-tab to),
identify the associated executables, group by executable, sort the
executables alphabetically, then sort the main windows alphabetically
once they have been grouped by executables, and have this done without
the user noticing any delay when the entire process is initiated each
time by clicking on a menu. The process fills the menu with menuitems
(the executables) then sub-menuitems (the main windows). However,
there is a fairly appreciable delay when enumerating all processes and
their modules (including the dll modules), then representing the
information in treeview.
The differences? When performing working with the windows, I am using
p/invoke (i.e., static intern) to call Win32 api functions rather than
the DotNet api, representing a great deal less data (although the
amount of data I am making use of may be at least as great), and using
a menu rather than a treeview. I am beginning to think that greater
use of the ability to intelligently set the capacity could speed
things up (with respect to the treeview), but I am also beginning to
the that greater emphasis needs to be placed by the developers of
DotNet on the optimization of their api, at least within certain parts
of System.Diagnostics. Has anyone had similiar (or different)
experiences?