As we start to plan our strategy, it is always a good idea to take a look at what has already been implemented by other people. Under the Win32 operating system, there are different ways of seeing which processes are running at any one time. Pressing the Ctrl+Alt+Del key combination, Windows 95 offers a list of the running applications but only those with a window:

On the other hand, Window NT provides an enhanced native process viewer named Window NT Task Manager, which displays, among many other things, memory consumption per running process, but not the process’s main window title:

Visual C++ includes two other tools which may help you. In addition to enumerating the windows and watching the messages ballet, Spy++ displays the running processes and their windows:

Spy++ provides this kind of hierarchical display when you select the Spy/Processes menu or by typing Ctrl+P. The meaning of each of the icons is as follows:

A variant of Spy++ and the process viewer tools are also available in the Microsoft Platform SDK, and can be downloaded free of charge from the Microsoft Website.

However the best tool to see the running processes is called Process Viewer. The installed executable file and location depend on the version of Windows you are using. For Windows 95, Microsoft Visual Studio\common\tools\win95\Pview95.exe has the following icon:

The corresponding Windows NT file Pview.exe has this icon:

Visual C++ installs a console mode application called pstat.exe in the Program Files\Microsoft Visual Studio\Vc98\Bin\Winnt directory. This tool provides the list of running processes and their threads:

pstat.exe is very useful when you want to find out why an application or one of its threads is blocked. Lastly, you can also discover the list of kernel mode components of Windows NT:

Through the document template, a CAplDoc document is created and bound to a CMainFrame window which wraps the three views within two nested splitters:

As you have already seen in Chapter 13,the application keeps a pointer to its main window. Our CMainFrame object will contain splitters with views inside. As usual, each view can access its document using its GetDocument() method. We will see later how the document is used to give a high level access to process and module description.

It’s time to invoke AppWizard and choose the options to create the application skeleton which will match our user interface design. Create a new project workspace by selecting MFC AppWizard (exe) as the project type and defining Apl (Advanced Process List) as the project name:

Select SDI as application type with Document/View architecture support.

Remove ActiveX Controls support.

As we will not be supporting printing, remove Printing and Print Preview, and set to zero the number of files stored in the recent file list. Click the Advanced... button and set the Main frame caption as Advanced Process List. Notice that we won't check the Use split window checkbox in the Window Styles tab. Although we want a splitter, this does not specify the kind of splitter you get when you check this option:

Choose the Windows Explorer project style. With this style selected, AppWizard will generate a skeleton application with a main window split vertically: a tree view in its left pane and a list view in its right pane. The next step will allow us to choose the name of the classes corresponding to each pane.

This final step is dedicated to changing the name of the classes generated by AppWizard. We keep the right pane view as CAplView but replace CLeftView by CParentView and the corresponding header and implementation files with ParentView instead of LeftView.

You can now compile the project typing F7 and execute the empty application with Ctrl+F5: Alternatively you can select the Build option from the Build menu to compile and link the project and then Build | Execute Apl.exe to run.

The code generated by AppWizard does not take into account some of the layout options you might have chosen in Visual C++, for example the Tab size and Indent size options in the Tools | Options | Tabs menu:

If you prefer to use whitespace characters instead of Tab characters when indenting code, this is not taken into account by AppWizard – it sets tabs as the default when it inserts code. However, you can easily convert the tabs into whitespace. Just select the Untabify Selection option from the Edit | Advanced menu (or type Alt+E followed by A and N), having selected a section of text to be converted..

You can also select Edit | Advanced | View Whitespace or type Ctrl+Shift+8 and to see the tab and whitespace characters (just like in Microsoft Word when you check ).

For the moment, our project does not have many classes. However, as you add new classes this alphabetically sorted list will prove difficult for you to make sense of them. It is a good idea to create folders and place your classes inside them with a simple drag and drop. For this particular project, we will need four new folders. Visual C++ allows you to create folders in the ClassView window and move your classes inside. These are the folders that you will need:

Right-click on AplClass and select New Folder… before changing the name of the folder to "Application & Frame". Do the same for the other three folders.

First of all choose your own application icon and, if you so wish, redesign the About box. To achieve these two tasks, click on the ResourceView tab and change the IDR_MAINFRAME icon and the IDD_ABOUTBOX dialog resources:

The interesting fields to update are the FileVersion and ProductVersion during the development of your application. You should also change the ProductName, FileDescription and LegalCopyright.

File | Open, File | Save, File | Save As, Edit | Undo, Edit | Cut, Edit | Paste.

File | New to File | Refresh

View to Options

After renaming File | Refresh, you should also change the shortcut into F5 and the associated text which appears in status bar and tooltips, as shown in the following dialog box:

The application toolbar also needs to be updated by removing unwanted buttons, in adding access to new features such as the font selection and in changing the File/New button into Refresh with a neat smiley.

AppWizard has generated source code which is responsible for the list view options we have just removed from the resources. This code has been added to the frame window and so open MainFrm.h and MainFrm.cpp to start editing.

First, in the header file, remove the declaration of GetRightPane(), a helper method giving access to the CAplView right pane of the splitter:

Still in MainFrm.h, remove the declaration of the handlers which were called to update the user interface of the toolbar according to the style of the list view in the right pane and to change that style:

Next, remove the implementation code for these three methods at the bottom of MainFrm.cpp without forgetting their association inside the message map macros at the top of the same file.

Finally, AppWizard has added a method to CAplView which is triggered when the style of the view is changed. Since we only support the LVS_REPORT style, you can delete its declaration in AplView.h:

Delete its implementation in AplView.cpp:

AppWizard generates OnDraw() methods for CAplView and CParentView to allow you to insert drawing code for these views, but as they are derived from CListView and CTreeView respectively, you will not need to implement the drawing code since it has already been done by the Windows control. Remove the OnDraw() declarations from the header files and their implementations in the corresponding .cpp files.

After the main frame window and its views, you have to remove some code for the document. Since we don't want to save the content of our document, we don't need to implement its Serialize() method, so delete this method declaration from AplDoc.h:

Do the same in AplDoc.cpp for its implementation:

The default behavior of a SDI main frame is to construct its title by appending the application name (given to AppWizard in the Advanced dialog Main frame caption during Step 4) to the name of the document (usually the name of the loaded file). Since our application does not load any file, the string "Untitled" is used as document name and we get the following title string:

The easiest way to prevent the document name from appearing in the main window title is to remove the MFC frame style FWS_ADDTOTITLE from the main frame before its creation. The CMainFrame method PreCreateWindow() is the right place to do this since it is virtual and called by the framework just before the window is created:

Delete the existing implementation in MainFrm.cpp:

MFC defines by default FWS_PREFIXTITLE as another frame window style which only has a meaning if FWS_ADDTOTITLE is set. In this case, you keep the document name but instead of beginning the title with it, you get the opposite: the application name followed by the document name. This is the default style for MDI applications such as Microsoft Word.

You may be wondering why, unlike our previous sample, cs.style is set after having called CFrameWnd::PreCreateWindow(). The reason is simple. Since it adds FWS_PREFIXTITLE, it would have been useless to remove FWS_PREFIXTITLE before calling it.

AppWizard has already done a part of the job to implement a splitter oriented user interface for us. A CSplitterWnd member has been added as a protected member of CMainFrame, as declared in MainFrm.h:

The splitter is initialized using the OnCreateClient() method in MainFrm.cpp. This virtual method is called by MFC (by the CFrameWnd::OnCreate() message handler) when the frame window is created. Its aim is to create the view which will be contained by the frame within its client area, that is the frame window without its title, menu and borders. Both the toolbar and status bar are created in OnCreate() and after OnCreateClient() returns and they will share the client area of the frame with the splitter.

The default MFC CFrameWnd implementation is to create an instance of the view class given to the CDocTemplate creation in the application InitInstance(). Let's see what has been implemented by AppWizard in order to get a splitter with two vertical panes:

First, m_wndSplitter is initialized as a static splitter using its CreateStatic() method. The first parameter specifies the window parent of the splitter. Next, the last two parameters state that the splitter will have 1 row and 2 columns. In fact, a splitter is a window which contains other windows (views most of the time) separated by a 3D line — this is close to a dialog box with no title. The screen shot below shows you the result of the previous code:

Once the splitter exists, each associated view may be created using CreateView(). The first two parameters indicate which splitter pane the view will be held in, using a row and column position. As CDocTemplate, a run time class description is needed as the third parameter in order to be able to create dynamically an object of the class in question. Therefore, the left pane, at row 0 and column 0, will be a CParentView instance and the right pane at row 0 and column 1, will be a CAplView object.

The fourth parameter gives the desired size for each pane. In fact, it is only useful for the first pane since the other will use the left over free space. The last parameter pContext is used by the view to bind itself to its document which is stored in pContext.m_pCurrentDoc.

It is not difficult to change this piece of code to insert an inner splitter with two rows and one column in the right pane of the outer splitter m_wndSplitter:

First, you add another protected CSplitterWnd member m_wndSubSplitter to CMainFrame in MainFrm.h:

Next, you should define a new class named CModuleView derived from CListView which will be used as the lower pane of the inner splitter and insert it inside the Document & Views folder within Visual C++ ClassView pane. To do this, right click on the Apl Classes root and select New Class.... Choose the name of the class and its base class before accepting your choices by pressing the OK button:

As with AppWizard, and for the same reason, you can remove some source code automatically generated by ClassWizard for the OnDraw() method. Open ModuleView.h and remove its declaration:

Delete its implementation from ModuleView.cpp:

However, ClassWizard did not implement default support for the GetDocument() method. We will follow the same mechanism used by CParentView and CAplView with an inline version for the release version and a more "verified" implementation for debug builds. First, declare CAplDoc by including the document header file at the top of ModuleView.h:

Write the debug implementation in ModuleView.cpp, after AssertValid() and Dump():

Then, add #include "ModuleView.h" at the beginning of MainFrm.cpp to allow you to use the class during the splitter initialization.

Finally, in OnCreateClient(), instead of creating a view for the second pane, define m_wndSubSplitter as the left pane. You just have to create its upper and lower panes the same way as AppWizard has done:

This part of the code is almost the same as that generated by AppWizard except for the arithmetic used to calculate the frame client area size. As explained earlier, the outer splitter m_wndSplitter will share the frame client area with the toolbar and status bar. Since both are created after OnCreateClient() is executed, we can only guess the space which will be needed by the bars when assessing the amount of the space needed for the splitter.

As you can see, the parent is the outer splitter &m_wndSplitter and m_wndSubSplitter is inserted in the parent’s right pane, corresponding to the parent’s first row and second column. You may have noticed that the row and column values are zero-based.

The main difference between this call to CreateStatic() and the previous one lies in the last two parameters. They indicate that m_wndSubSplitter is a child window of m_wndSplitter and is embedded into the pane specified by m_wndSplitter, corresponding to IdFromRowCol(0, 1), i.e. the right pane.

As usual, when you want to write some code to implement a new feature, try to find out if anyone else has already done it. Even if you think it is a waste of time to browse the samples given with Visual C++, you'll learn quickly it is worth the effort. If you don't want to get lost among the hundreds of samples provided by Visual C++, you should begin by searching "MFC Samples Index" in the online help.

Indeed, the SUPERPAD sample implements the following feature:

As you can see, these two helper functions rely essentially on two functions which allow you to store/retrieve information to and from the application INI file or Registry. CWinApp provides GetProfileString() to get the string associated to a given section and entry, while WriteProfileString() does the opposite by overwriting the entry value of the section with the given string.

You have seen in Chapter 13 how SetRegistryKey() can be used to choose where the Get/WriteProfileString() methods will store/retrieve their data. AppWizard has generated the following code for us, at the beginning of application InitInstance():

If you comment out this line, the Registry will not be used, and an INI file will be created instead. This file has the name of the application (in our case APL), .ini as extension and is stored in the Windows directory. Otherwise, if you keep on calling SetRegistryKey(), you should provide your own string such as your company name:

The WINDOWPLACEMENT structure, which is saved and restored in a string format, contains information about the placement of a window on the screen:

In addition, CMainFrame class gets two additional methods that call these two window placement helpers:

This method will be called in the InitInstance()method, after the frame window has been created.

In order to remember the frame’s size and position, its OnClose() message handler for WM_CLOSE retrieves its placement and saves it using the WriteWindowPlacement() helper.

To end this sample code description, you should know that in order to change or retrieve the placement state of a window, the Win32 API provides two functions, SetWindowPlacement() and GetWindowPlacement(), which both take a window handle as the first parameter and a pointer to a WINDOWPLACEMENT structure as the second parameter.

In order to reuse the sample code from SUPERPAD, the first idea which comes to mind (after having read Chapter 10) is to define an inheritance relationship:

First, define a class CFrameWndEx, derived from CFrameWnd that stores its size and position upon closure and restores itself upon creation. Next, derive CMainFrame from CFrameWndEx instead of CFrameWnd. That way, next time you need to have a main window to position itself in another project, you just have to derive from CFrameWndEx.

This is called by the two previous members in order to know under which section the position should be saved into the Registry/INI file. In the SUPERPAD sample, these parameters were defined in static variables szSection and szWindowPos. If we want to allow different frames to store their placement, they should be stored in different places. This method is supposed to have been overridden by the derived classes. It is a good habit to declare such a methods as pure virtual in order to detect the guilty derived class which does not override it at compile time.

We should take the time to think about the pros and cons of this solution. First, it relies heavily on C++ inheritance which means that only classes derived from our CFrameWndEx could benefit from this auto-save behavior. If you want to provide the same feature for a dialog box, you are forced to copy and paste your code into a new CDialogEx class, derived from CDialog. And what to say if we want to add this auto-save feature to a property sheet? Perhaps, you begin to discover the flaw in this inheritance-oriented reuse solution.

If the solution does not lie in an inheritance relationship between classes perhaps it will be better to use a containment relationship. We define another class which implements the Load/Save feature independently from CDialog or CFrameWnd or every other window-based class. The idea is to add a member of this new helper into classes which need its Load/Save feature.

In fact, if we know the window handle corresponding to the frame or the dialog, plus where to store the placement description, the class no longer needs to derive from a special frame or dialog class. You can therefore declare a new class derived only from CObject with the required Load/Save methods. Then add one instance of that class as a member of any window which needs to save and restore its position. To create such a new class, right click on Apl Classes root in ClassView pane of Visual Studio and select New Class.... Insert the name of the class and its base class before validating with the OK button:

Don't be afraid by the notification box which follows. It informs you that, you, the user, will have to include the appropriate header files for the CObject class as the Wizard cannot do this. However, as CObject is defined in stdafx.h, we won't have to add any new header files, but since we want to reuse the class in applications other than APL, you should remove the following line from WndSaveRestoreHelper.cpp:

The only parameters the new class requires are the window handle plus the storage area — it will do the rest. Here is the declaration of the CWndSaveRestoreHelper class :

The protected members are used to store the parameters needed to save and restore a window position, that is the section and entry where the position description will be saved in addition to the window handle. Next, we provide two ways to pass the parameters: either by constructor which needs all parameters or by dedicated methods for each parameter. We have changed GetSectionName into SetSectionName since we won't override the method, as in the CFrameWndEx idea above. Instead, we call it to set the values. It is always a good habit to choose a name which means what the method is supposed to do, since it is always difficult to predict how such an helper class will be used.

Before digging into this helper class implementation, let's see how to use CWndSaveRestoreHelper with the application frame window. First, just add a protected instance to the CMainFrame class in MainFrm.h:

You should always remember to set pointer members to NULL in the constructor and don't forget to delete them if needed in the destructor:

The m_pPositionHelper can only be created once the window handle is known: the frame's OnCreate() message handler seems to be a good place for that:

It is also possible to allocate m_pPositionHelper in the CMainFrame constructor combined with with SetSectionName() and only call the AttachToWindow() method here. It is up to you — the helper class is flexible enough to support different programming styles.

The tricky part of the job is finding out when to ask the helper member to restore the frame position and state without conflicting with the default MFC processing. Indeed, using the document/view architecture, it is not possible to call Restore() within the OnCreate() method. The reason lies in the fact that the creation of the frame is totally managed by the MFC framework in general (and by the document template in particular) which keeps on monitoring the frame state (visible, maximized or minimized) after its OnCreate() has been executed.

Therefore, we need to use ClassWizard to define a new CMainFrame public method called RestoreFramePosition() which will be called at the end of CAplApp::InitInstance(), once MFC has done its job. Right-click on CMainFrame and choose Add Member Function… from the menu. Type in the new function’s type (void) and its name, press Add and Edit and once the Wizard has finished its work, add this code to MainFrm.cpp:

Notice the call to CWnd::CenterWindow(). When it is not possible to retrieve any saved position or size, the window will be placed centrally on the screen.

MFC uses m_nCmdShow to display the application’s main window. Since we set it to SW_HIDE, it will be set to invisible. After ProcessShellCommand(), when MFC has created everything from the document to the frame, we can then ask the main window to restore its position.

Next, call SaveWindowPlacement() when it is time for the frame to save its position in its OnDestroy() message handler. Right click on CMainFrame in Visual Studio ClassView pane and select Add Windows Message Handler...:

Finally, add the code below to MainFrm.cpp:

Finally, let’s see our implementation for state saving and restoring methods. The ideas behind the source code for the helpers have been taken directly from the SUPERPAD Visual C++ sample which has been presented earlier. First, it is possible to set the section and entry under which the window position will be saved thanks to a enhanced constructor:

This function returns TRUE, if the given window is valid and FALSE otherwise.

When it is time to save the associated window position the CwndSaveRestoreHelper member function Save() is called:

If the helper object has been initialized and the window is valid, its placement is translated into a string and stored using WriteProfileString().

If the helper class has been initialized, the saved window position and state are retrieved in string format using GetProfileString() and transformed into a WINDOWPLACEMENT structure. Then, the window placement is updated using SetWindowPlacement() and ShowWindow().

In our application, we will need to display the process and module descriptions as a CListView object. Let's describe roughly how to use the CListView class in a superficial way. In order to get a deeper explanation of CListView, you should read Chapter 8 of Professional MFC with Visual C++ by Mike Blaszczak published by Wrox Press. In addition to this book, you should take a look at CMNCTRLS, ROWLIST and LISTHDR samples provided with Visual C++.

Unlike Windows Explorer, we will associate no image to an item in any of our CListView derived views. You will be taught soon how to do it for a tree view. Since the mechanisms are the same for a list view and a tree view, you will easily be able to apply this knowledge if you want to extend your list views with images for each item.

For our Advanced Process List application, we only need to display the process and module lists in report mode. Therefore, our first task we have to achieve is to enforce the LVS_REPORT style in the PreCreateWindow() method of each view. The following AppWizard generated code has to be removed:

In addition to setting the LVS_REPORT style, we restrict the list to single selection with LVS_SINGLESEL. If LVS_SHOWSELALWAYS is also included, the selected item will stay in the selection color even if the list view loses focus.

For the CModuleView class, you need to add the PreCreateWindow() virtual method yourself in right-clicking on the CModuleView line in the ClassView pane of Visual C++. Choose Add Virtual Function... in the menu and select PreCreateWindow in the left pane of the dialog which appears next:

After clicking the Add and Edit buttons, you just have to copy exactly the same source code as for CAplView.

Once the list view is created, we define the column names and fill the list with subitems. The CListView class does not provide a lot of functions to play with. It is just a C++ trick to manipulate a Windows "list view" control as a CView, in order to fit in the MFC document/view framework. In fact, CListView is just a wrapper around CListCtrl which really exposes the Windows control features. Once we have a CListView object, we get access to the corresponding CListCtrl implementation using GetListCtrl().

Add a OnCreate() message handler for both CAplView and CModuleView by right-clicking on the classes in ClassView pane of Visual C++ and select Add Windows Message Handler... before choosing WM_CREATE in the left New Windows messages/events list:

Then, once you have clicked the Add and Edit buttons, to define the columns, write the needed code for each method. We will take a closer look at the CModuleView source code in ModuleView.h:

Next, each column is defined in the OnCreate()method in ModuleView.cpp

The base class implementation is called first and a reference to the CListCtrl object is brought to life using GetListCtrl(). Then, each column is defined in a LVCOLUMN structure whose description is as follows:

You should notice that an iSubItem is associated with each column. We have chosen to match the position of a column with its subitem value: 0 for the first column, 1 for the second and so on.

The number of data members in this structure depends on which version of Internet Explorer is installed (hence _WIN32_IE). We will not be using these newer members iImage and iOrder in our application, so we can safely ignore them. The mask field sets which other fields are relevant using LVCS_xxx constants. In our example, every field will be filled. Finally, InsertColumn() is called to define each column.

Add the same kind of code for CAplView but define each column the same way with the following subitem values defined in AplView.h:

Estimate widths for each field (Column.cx values) and choose whether the title should be placed to the left (LVCFMT_LEFT) or right (LVCFMT_RIGHT). Here is how the resulting application should appear afterwards if you compile and run:

First, let's discover how to fill a list view. In fact, CListCtrl provides four ways to add an item to the list view through four versions of InsertItem():

Each ends up filling a LVITEM structure and sends it to the list view control. That structure has the following layout:

You can notice similarities with LVCOLUMN such as mask or pszText. Note alse we ignore the iIndent parameter.

First, the current content of the list view is removed with a call to DeleteAllItems(). Next, each line (corresponding to iItem) is added using InsertItem(). Its text "Item label" will appear in the first column of the list view. Each additional column is added to the current iItem (known by its iActualItem value returned by InsertItem()) using SetItem() instead of InsertItem(). You can see iItem as the zero-based line number and iSubItem as the zero-based column number.

If you add this code into CAplView::OnInitialUpdate(), this is what you get:

The other way to add lines to a list view uses a "callback mechanism" where the view itself asks Windows for the contents of the columns for each item. Instead of giving the text of each item and subitem during insertion, you just have to set pszText with LPSTR_TEXTCALLBACK. If this parameter is set, the list view will receive a LVN_GETDISPINFO notification message with a LV_DISPINFO structure (renamed as NMLVDISPINFO).

The item.mask field is used to define what field is needed such as:

The first field header of LV_DISPINFO is the following structure:

This allows you to determine which control (hwndFrom or idFrom) is sent the notification code. Here is sample code for such a notification handler:

Once the kind of notification is identified using pDispInfo->item.mask, a virtual method is called to get the text to be displayed for the column and the next move is to copy it back to the

pDispInfo->item.pszText field.

Since the notification only gives the notification code, you may wonder how we could associate a process or a module description to a particular item. The answer lies in the lParam field of the LVITEM structure which is set when an item is inserted into the list view. We will use this lParam to store a pointer to a process or module description. As you have seen in the previous sample code for the LVN_GETDISPINFO notification handler, this lParam pointer is available to get the description of each column corresponding to the process or module.

Replace the previous source code of OnInitialUpdate() with the following source code:

If you compare this version to the former one, you can detect two major differences. First, the subitems have disappeared. In fact, a LVN_GETDISPINFO notification is sent to get the text for every item and another for each subitem as you will see in the sample code. Also, we are using a helper method named InsertItem() which takes the lParam additional information as first parameter and the index of the item to be inserted. If iItem is set to –1, the item is inserted at the end of the list view.

This function builds a LVITEM structure item which describes an item whose text label will be retrieved on getting a LVN_GETDISPINFO notification, since LPSTR_TEXTCALLBACK is given as pszText. In addition to the pszText field, lParam is set with the method’s first parameter which is currently the corresponding item index. (It will later be a pointer to a process object for CAplView and to a module object for CModuleView.) Once item has been set, InsertItem() is called to insert it into the list view control.

Add a notification handler for LVN_GETDISPINFO in and fill it with the sample code given previously. To add such a notification handler, right-click on CAplView in the ClassView pane and select Add Windows Message Handler... to enter the following dialog:

Choose =LVN_GETDISPINFO in the left list and push Add and Edit button before confirming the name of the handler as OnGetDispInfo:

Add a new virtual method OnNeedText():

It may seem strange to implement the OnNeedText() method instead of directly building the column content in the OnGetDispInfo() notification handler. In fact, it is always a good habit to separate the data from the way it is used or displayed.

However, you should take care of the performance drawback introduced by this method: OnNeedText()has to run quickly if you don't want to slow down your application display.

We have saved the most difficult view for last. CParentView, which is derived from CTreeView. We want to represent the processes hierarchy within a Windows tree view control. Before digging in the tree hierarchy construction itself, let us see what it is possible to do with such a Windows control.

CTreeView is defined like ClistView — to present a Windows control (a tree view for the former and a list view for the latter) as an MFC view. It gives access to the low level class CTreeCtrl which provides most of the methods to manage a tree view. Even the words are confusing, and so, here are simple definitions to help you:

But, what can you expect from such a tree? First, you can insert items with a text label and, optionally, an image. Unlike an item in a list view which is known by an integer index, once inserted, a tree item is defined by a HTREEITEM handle. Next, when an item is inserted into the tree using InsertItem(), you need to know several additional pieces of information. CTreeCtrl provides four different versions of InsertItem():

Each ends up filling a TVINSERTSTRUCT structure and sends it to the tree control. That structure has the following layout:

As you can see by the test on _WIN32_IE, once more, features supported by tree controls depend on your Internet Explorer version.

Three parameters are important during tree item insertion. First, you need to know the handle of its parent item set in hParent. If the item has NULL or TVI_ROOT as hParent, it is called a root item. If you insert an item with the HTREEITEM of another tree item as hParent, the former is called the child and the latter, the parent.

Windows tree control displays in front of a parent item either a if its children are hidden or a if its children are visible. The user can click on these icons to expand or collapse the item subtree. This default behavior, which is what you have in Windows Explorer, can be modified if you change the styles used for the tree control. Note that you can update tree styles in the PreCreateWindow() method, so set the following styles in ParentView.cpp:

As with the CListView derived classes CAplView and CModuleView, we use PreCreateWindow() to assign the Windows class name WC_TREEVIEW to the new control and to set other styles. TVS_SHOWSELALWAYS ensures that the selected item background will stay highlighted even if the focus changes and TVS_DISABLEDRAGDROP prevents the user from dragging and dropping a tree item. The first three styles deserve to be explained in more details:

TVS_LINESATROOT TVS_LINESATROOT is missing

No lines, buttons or lines at root TVS_HASLINES |

TVS_LINESATROOT

TVS_HASBUTTONS is missing

TVS_HASLINES is missing

Returning to the TVINSERTSTRUCT structure, the hInsertAfter member defines how the tree item will be inserted, in relation to its parent. You can choose among the following three values:

And finally, item is used to define the visible "presentation" of tree item using a TVITEM structure which has the following layout:

You could find many similarities with the LVITEM structure used to define a list view item that we have already described. In fact, the main difference lies in the iSelectedImage and cChildren fields. In our case, the cChildren field is not used for insertion and you will soon see why iSelectedImage is needed.

As you will have seen with the above previews of CParentView, for each tree item, an image will be displayed in front of its text label. We did not use images when developing CAplView and CModuleView, but for CParentView we will introduce this feature. A tree allows you to define two different images per tree item — one is displayed if the item is not selected (set with iImage) and the other if the item is selected (set with iSelectedImage).

Unlike what we have done for our CListView derived views, we will set the iImage (and also iSelectedImage) field with a value. The mask fields have a meaning with ORed TVIF_ values. In our case, we will set the pszText, iImage, iSelectedImage and lParam fields. Therefore mask will be have the following value:

(Three other TVIF_ values are defined — TVIF_CHILDREN, TVIF_HANDLE and TVIF_STATE which enable the cChildren, hItem and state/stateMask fields to be set.)

So, what is the meaning of the integer value which will be set for iImage and iSelectedImage fields? Each field is an index to an image list which is associated to the tree using the SetImageList() method.

MFC provides the CImageList class which provides many methods for you to play with an image list. An image list can be created using the following five versions of Create() method. The first creates an empty image list:

The following two functions both create and initialize the content of an image list with a bitmap resource. The crMask color defines which color of the bitmap is treated as transparent as you will see soon.

The fourth of the five merges imageList1 starting at its nImage1 picture with imageList2 starting from its nImage2 picture whose width is dx and height is dy.

The last function duplicates the given image list.

Once an image list is created, you can add a new image inside with Add(), delete a picture with Remove(), replace a picture by another with Replace(), and even save/restore it with Read()/Write(). In our case, we are just interested in creating an image list from a bitmap resource and associating it to our CParentView.

Let's first create the bitmap resource. Click on the ResourceView pane in Visual Studio, right click on Apl Resources and choose Insert... in the contextual menu. Ask for a new bitmap resource in the following dialog and push the New button:

You reach a blank page in Visual Studio and your first task is to set the dimensions of the bitmap before drawing each picture. Double-click anywhere in the page to make the following Bitmap Properties dialog appear:

In our tree, we need to make the difference between three kinds of processes — those with children, those which have spawned no other process, and the root of all processes, called NT. That is why 54 = 18*3 is set as the bitmap width. Here are the pictures for each, drawn in the IDB_PARENT_IMAGE_LIST resource bitmap:

The next step to achieve is to create the image list from the bitmap resource and to associate it to the CParentView. Right click on CParentView in the Visual Studio ClassView pane, choose Add Windows Message Handler... and select WM_CREATE in the left list before pushing the Add and Edit button. Open ParentView.h and declare the constants below:

In ParentView.h implement the OnCreate() method with the following code:

First, a bitmap is loaded from the application resources using its LoadBitmap() method. Its dimensions are retrieved using its GetObject() method. Then, its width and height are used as parameters to create the image list using one of its Create() methods. We could have used the Create() method which directly loads the bitmap from the resource into the image list, but the chosen solution allows you to learn how to load a bitmap from a resource using LoadBitmap() and GetObject() to retrieve its dimensions.

Once the image list is created, the loaded bitmap is added to the image list using Add() with the bitmap as first parameter and a mysterious second parameter. The light gray color defined by RGB(192,192,192), and provided as second parameter, must be seen by the image list as transparent. This is the reason why the background of our IDB_PARENT_IMAGE_LIST resource bitmap is light gray.

To complete the implementation, we need to associate the image list with CParentView using SetImageList(). Do not forget to declare the image list as a protected member in ParentView.h:

You have to remember to clean up the image list before the view disappears. Add a message handler for WM_DESTROY the same way as for WM_CREATE and write the following code:

As you have seen, we created the image list using WM_CREATE, and not using the class constructor. We have two reasons to do this:

Let's go back to the insertion of an item in CParentView. We have already seen the values needed for most of the TVITEM fields before calling InsertItem(). We will use the same notification mechanism as we have used for CAplView and CModuleView. To achieve this, we will set lpszText field to LPSTR_TEXTCALLBACK before calling InsertItem().

Although it is interesting to use the notification mechanism to reduce memory consumption for processing text labels, the same argument is not obvious for tree item images which are stored as integers. Therefore, iImage and iSelectedImage will be set to one of the predefined constants STATE_PARENT, STATE_CHILD or STATE_ROOT and not I_IMAGECALLBACK.

Define a message handler for TVN_GETDISPINFO and write the code below for its implementation:

We first check whether OnGetDispInfo() has been executed to retrieve the text label. Next, we delegate the burden of attaining the text label to virtual method OnNeedText(), as we did for CAplView and CModuleView:

Up until now, you have learned how to build the application user interface. The following paragraphs will explain how to access process and module descriptions under Windows NT before digging into the MFC document/view architecture. The last part of this section will put things together and reveal the source code to fill CAplView, CModuleView and CParentView.

Among the helper functions provided, EnumProcesses() gives access to the running processes:

Once the list is retrieved, the next task is to get the whole process description from its process ID. Most of Win32 API functions related to processes and modules need a process handle as parameter but we just have an ID. A process ID can easily be transformed into a process handle using OpenProcess():

We don’t need to inherit handles from the process and so PROCESS_QUERY_INFORMATION | PROCESS_VM_READ will be enough for the access flag. After having used this process handle, we must not forget to give it back to the system. The CloseHandle() Win32 API function is responsible for this clean up task.

To get the process’s internal name, GetModuleBaseName() is the perfect candidate:

If hModule is NULL, the process’s internal name is copied into lpBaseName, including the .exe extension, which will be removed when showing the process in the list view.

GetModuleFileNameEx() retrieves the process executable’s full pathname, only if hModule is set to NULL. It is stored in the lpFilename buffer:

However, the Win32 API online help tells us that GetWindowThreadProcessId() returns the ID of the process which has created a given window, filling lpdwProcessId with the ID of the process responsible for the creation of the given hWnd window:

On the other hand, EnumWindows() allows you to list all top-level windows and get their handles:

The lpEnumFunc callback function given as the first parameter has the following prototype:

This callback will be called with each top level window handle as the first parameter. The lParam is the same value given as second parameter to EnumWindows(). Once the window‘s handle has been retrieved, GetWindowText() will give us its title.

Since a process is allowed to create more than one top-level window, you are not certain of quickly finding the one that is visible to you, the user. One simple algorithm is to look for each top level window using EnumWindows() and compare its process ID with the given process. Either the window is visible and has a title, in which case you can stop the search, or else save its handle and keep on searching. It may be useful to store the handles of all the windows even if they don’t have a title, since some applications only create hidden windows.

Here is the code for the helper function which passes an ENUMINFO structure to EnumWindows(), and returns the more plausible window, from the visible window with a title to the invisible window without a title:

Finally, we define the callback function which returns FALSE when a visible titled window of the process is found and TRUE otherwise, to keep the enumeration going:

Note that lParam corresponds to the PENUMINFO structure given as a parameter to EnumWindows(). For each window, the identifier of the process which created it is retrieved using GetWindowThreadProcessId(). It is then compared to the process ID passed to lParam as a search parameter, and if there is a match, the hWnd handle is saved in the search structure. Only if the handle corresponds to a visible, titled window does the search end.

This method of getting a top-level windows for each process is not very efficient. Instead of enumerating the top-level windows once per process, it would have been better to call EnumWindows()once and, with each window passed to a callback function, filling up a map with a process ID as a key and an EnumInfo object as a value. At the end of enumeration, you could retrieve one window per process ID using Lookup(). This would be a good exercise left for you to do.

When you talk about the memory consumption of a process, several parameters may be presented to the user. Window NT provides an application where you can find many in depth information about memory. If you open Administrative Tools folder from the Start menu, you get access to the Performance Monitor:

If you select Process as Object, you can see the counters associated to a process that Windows NT keeps track:

When you push the Explain>> button, you get an description of each counter. For our project, we are interested in the Working Set size which corresponds to the Mem Usage column in Windows NT Task Manager.

The GetProcessMemoryInfo() function from PSAPI fills the following PROCESS_MEMORY_COUNTERS structure:

Among these counters, WorkingSetSize represents the physical memory actually used by a process, which is what we are looking for.

The source code for the Performance Monitor is available under the SFL\SDK_SDKTOOLS_WINNT_PERFMON key in MSDN Samples. It is not easy to understand the way the counters are retrieved. However, all that you need to know is accessible through the Registry. Unfortunately, access to the details of these Windows NT components in the Registry is much more complicated than with PSAPI, but if you are patient and feel bold enough to explore the PerfMon sample, you will be able to make great improvements to your Application Process List.

For information about the parent process and the handle count, we turn to articles published in the MSJ. In the article: "Under the Hood" by Matt Pietrek (published January 1997), the NtQueryInformationProcess() function from the DDK is presented. All you need to know here are the parameters to use in order to get the parent process ID and the handle count. To get a broader description of this ntdll.dll function, and its other uses, you should refer to this MSJ article. For our project, you get the parent process ID using this code:

If you pass ProcessBasicInformation as the second parameter, you get the ID of the process which spawned hProcess in the InheritedFromUniqueProcessId field of the third parameter. Getting the handle count is even easier:

In order to use this function, we need to include the file NtQuery.h which sums up the needed declarations from the Windows NT Device Driver Kit (that is the DDK) without redefining anything already declared in Windows.h and the .lib file corresponding to the functions exported by ntdll.dll. From this file, NtQueryInformationProcess() will be called.

Create a new header file called NtQuery.h and add it to the project. Copy the following code to NtQuery.h:

Before we set about defining C++ classes to wrap the code we have presented in this section, there is one last area left to discuss, the module list. This is taken care of by the PSAPI function: EnumProcessModules(). It returns the list of modules loaded by a process through HMODULE. Another function, GetModuleInformation() will give us a more detailed description of the modules in the list. Given a process handle and an HMODULE, it fills the following MODULEINFO structure:

lpBaseOfDll gives the address where the module has been loaded in the process address space, which is just what we want. We don’t really need to call this function since HMODULE has exactly the same value as lpBaseOfDll. GetModuleFilenameEx() returns the DLL or executable filename corresponding to the module.

You have seen how to access Windows NT running processes and loaded modules. Now we will develop a set of classes which will easily fit into the user interface classes we have already defined. Four new classes will be designed: CProcess, CModule, CProcessList and CModuleList.

Right-click on Apl Classes in Visual Studio ClassView and choose the New Class... menu item. Follow the same steps in creating the calsses as you did for the CWndSaveRestoreHelper class,and then place all the files in the Process & Module folder. We want the declarations and definitons of classes CProcess and CProcessList in the same .h and .cpp files. You have to push the Change... button and select another filename in the case of CProcessList:

Do the same for CModuleList. After completing these steps, you should have:

In most classes generated this way, ClassWizard adds the line #include "apl.h" into the.cpp files. To ease a future reuse of your classes, you should remove this directive from both files. Failure to do so will prevent successful compilation, if you reuse these classes in another project.

The CModule and CProcess classes will have two purposes. First, the description of a process and of a module will be made available to the user through a set of public methods. The data members will be kept hidden and only Get…() methods remain as public. Second, the class should be able to get the description of each field accessed by the Get…() methods, given an ID for a process or an HMODULE for a module. For the CModule class, the constructor will serve this purpose, whereas for CProcess, a special function AttachProcess() will carry out this task.

Here is the CModule class declaration:

Note that CModule is derived from CObject. Even though there is a significant memory overhead in deriving from CObject, keep in mind a significant advantage of doing so: it makes it easier to find and debug memory leaks. When you run the application in Debug mode (F5 key), a memory check is done on your behalf. When the application terminates, if a memory block has been allocated using new but not released using delete, you get a description of this block. To illustrate this, let us see what happens with a simple example. Create a CModule object in the free store but do not add and code to delete it afterwards. Write the following code in CAplApp::InitInstance():

The trace output is different depending on whether CModule derives from CObject or not:

In addition to our CModule object, we can see that its m_szFilename member, strcore.cpp(116), has not been deleted either. For our CModule object both examples of output display the source file ( in this case F:\WROX\Apl\Apl.cpp) and the line of code (109) where the memory allocation occurred.

The only difference is the way the object is displayed. In the first case, where the CModule object is not derived from CObject, the memory dump output is not easy to decode. In the second case, the address returned by new is returned, as well as the size of the object (here 12 bytes long) and it's class type, erroneously displayed as CObject.

As explained in Beginning VC++6 Chapter 18, it is possible to get CObject features only if you use certain macros. In our debugging example, we have only forgotten to implement the first feature level with DECLARE_DYNCREATE() in the CModule declaration and IMPLEMENT_DYNCREATE(CModule, CObject) at the beginning of Module.cpp implementation file. If you add these two macros to their repective files and run again, the resulting output is as follows. This time the right class name appears in the dump:

First, in order to ensure a better trace output, you are encouraged to enhance the level of traces in Debug build. To do this, add the following lines to the beginning of your application CAplApp::InitInstance():

And insert this code into CModule::Dump():

In this case, the internal description of the leaked object is displayed. After calling CObject::Dump() to let MFC dump the class name, you enumerate values for every class member.

The implementation of CModule methods is straighforward. First, you need to add what is missing for the CObject feature level support we need. In Module.h, before the CModule constructor declaration, type:

At the beginning of Module.cpp type:

Now we can start implementation in earnest. Note that two CModule constructors have been declared, a private deafult constructor and a second public constructor with two parameters:

AssertValid() checks that the filename is not empty or the loading address is not 0:

Dump() helps you find memory leaks:

Let's now develop the CProcess class:

This class is a little bit more complicated than CModule. Before implementing it, don't forget to insert the following line to the beginning of Process.cpp:

First, there are many more members than for CModule, and we have chosen not to use a special constructor which would have too many parameters. Instead, we let a CProcess know how to describe itself if we pass a process ID. We have already seen which system API is worth using to set each CProcess member knowing its process ID. The AttachProcess() method is responsible for doing this initialization job and returns TRUE if it is possible to get the process description for the given ID. You will discover soon why it is declared as a private member. Here is the source code:

Most of the source code has already been explained except for two parts. First, if the process ID given as the parameter has a negative value, we define3 the process as "System Idle Process", which emulates the Windows NT Task Manager. Second, just before releasing the process handle, we ask the process's module list to fetch each loaded module with Refresh(). We have already explained how to get such a list using PSAPI functions but you will soon discover its integration within CModuleList.

Now cut and paste the source code for the windows enumaration functions which we discussed earlier: EnumWindowsProc() and GetMainWindow(), in that order. Since these two functions will appear in the Globals folder, insert their declarations in Process.h outside the class definition. Also include Module.h at the top of the header file, as you are declaring a CModuleList data member. In addition you must copy and paste the definiton of our ENUMINFO structure into Process.cpp, and include the header file NtQuery.h. At this point you will also need to include the file Psapi.h, in order to use the EnumProcesses() method, which we introduced right at the beginning of this section. This file is found in the Samples folder on the MSDN library setup disk.

We have also added DefaultInit() to initialize each member with default value:

Afterwards, a set of Get…() methods is defined that gives access to each field of a process description. The public side of a declaration also contains four methods which have not been introduced yet. First, GetModuleList() returns a reference to a CModuleList object which will provide several methods to enumerate the modules loaded by a process. We shall discuss the enumeration methods soon, while describing CModuleList and CProcessList classes.

In Chapter 8, you have seen that a function declared as friend in a class can access any class member even if it is private or protected. The same can be done for a class. Since CProcessList is declared as friend of CProcess, CProcessList is allowed to access the private members of CProcess. CProcessList can create instances of CProcess objects and associate them to a process given its ID (using its private AttachProcess() and AddChild() methods).

The major drawback of declaring CProcessList is a friend of CProcess is that it binds these two classes together, but in doing so, we hide low level tricks needed to get the process ID. The highest level class is therefore CProcessList, from which it is possible to get each running process, and that will be introduced just after the explanation of the management of spawned processes.

The list of processes which have been spawned is stored into a CObArray member called m_ChildProcesses:

This kind of array provides the same kind of services as a templated array. It is used to store pointers and that is exactly what we need: storing pointers to the CProcess object corresponding to each spawned process. Here are the two methods defined by CProcess, to access to its child processes. AddChild() adds a CProcess object as a child into the array. It is called by CProcessList when it takes a snapshot of running processes:

GetChildrenCount() retrieves the number of child processes it has started. It is used by CParentView in order to set a different icon for whether a process has started other processes () or not ().

Finally, implement each Get…() method to return the corresponding member. Insert the code after the defninitions in Process.h to make the methods inline. For example the following method returns the process name.

The next stage in our project is to get the process and module lists. It is the responsability of enumeration classes to let you access running process and, for each, give you the list of loaded modules with CProcess::GetModuleList().

The three main goals of enumarator class CProcessList are:

Here is the declaration of CProcessList:

The three main features of CProcessList are carried out by the following public methods:

You have been introduced to CTypedPtr… data structures in Chapter 16, and we are using a CTypedPtrMap to store each process description (a CProcess object). The key is the process ID and the value is a pointer to the object.

In order to use templates, you need to include <AfxTempl.h> in your header file. Before exploring the implementation of the main CProcessList methods, don't forget to add the following line before the constructor:

As it has been explained earlier, PSAPI functions are used to retrieve the process list in Refresh():

m_ProcessMap[(LPVOID)dwProcessID] = pProcess;

1) Since Refresh() will be called several times, we must empty the map and delete each process description before filling it up again. This is the role of DefaultReset():

If the map is not empty, each element of the map (which is a pointer to a process description) is retrieved and deleted (using a GetStartPosition()/GetNextPosition() loop). Finally, the map is emptied by calling RemoveAll().

Since we don't want to generate any memory leaks, we must not forget to call DefaultReset() from the CProcessList destructor as well:

2) A CProcess object is created using new; and initializes itself with AttachProcess(). If its initialization has been successful, the pointer to the CProcess object is stored into m_ProcessMap, and associated to its ID via the m_ProcessMap’s [] operator:

If it is not possible to get the description for the given process ID, the CProcess object is deleted and therefore, not inserted into the map. This should never happen.

3) For each process already in the map, the list of processes that it has spawned must be built. Here is the source code for the SetChildrenList() helper method:

The idea is simple. Since we know the parent of each process, we just have to list every process in the map, and for each, get its parent description and add itself as a child of its parent. Each CProcess keeps track of its children in a CObArray member called m_ChildProcesses. AddChild() helps us to do this easily.

Our CParentView and CAplView will need to get a process description knowing only its ID. CProcessList provides GetProcess() which does this kind of job:

This method relies on the Lookup() method which returns the value associated to a key. In our case, the "key" is the process ID and the "value" is a pointer to the process description.

In several parts of our APL application, we will need information about the list of running processes. The CProcessList class is dedicated to providing the required methods. First, GetCount() returns the number of running processes:

The following methods give an easy way to get each running process managed by CProcessList, but hide the way they are stored:

Each method returns NULL if the given position is not valid or if there are no more processes in the list. Later you will see the source code to populate CParentView and CAplView using these two methods.

Each process contains the modules it has loaded inside a CModuleList object. Here is the class declaration:

The class provides in its public interface Refresh() to store modules loaded by the given hProcess:

The pseudo-code for this method has already been introduced in the description of PSAPI functions. Insert the following line at the top of Module.cpp:

The main idea of Refresh() is to create one CModule object per module returned by EnumProcessModules() and to store the pointer to it in a CObArray. Why do we use a CObArray and not a map collection class? Unlike CProcessList which needs to be able to retrieve a process description for a given process ID, we just need to enumerate each module, one after another. An array collection class is perfect for this kind of job.

You can see from the Refresh() source code how the low level module data is wrapped by our C++ classes. Since Refresh() may be called several times, we need to empty m_ModuleArray before filling it up again. FreeModuleArray() retrieves each CModule pointer stored in m_ModuleArray and deletes it:

Even though each CModule object has been deleted, we must also empty the array itself by calling the RemoveAll() method. Once a module description (loading address and corresponding filename) is known, a CModule object is created:

Finally, the new CModule pointer is stored into m_ModuleArray:

Once a snapshot has been taken, GetCount() returns the number of loaded modules and returns the number of CModule pointers stored in m_ModuleArray:

Finally, GetFirst() and GetNext() offer an easy way to iterate through each module in sequence.

We follow exactly the same principle as for the GetFirst() and GetNext() methods of CProcessList, by completely hiding how the snapshot is stored internally. They return NULL if the given position is invalid or if there are no more modules in the snapshot. You will see the details of how they are used when we explain the filling of CModuleView.

It is now time to introduce you to compiler features which are usually hidden from novice developers: the pragma. The Visual C++ online help defines #pragma directives as the following:

Among the strange and powerful pragmas provided by Visual C++, one is heavily used by the MFC framework to ensure that the right MFC runtime DLL is linked. You can define which DLL you want statically linked within the project workspace through the project settings or directly in the Visual Studio FileView pane:

Alternatively, you can add a pragma in your source code to do it yourself using the pragma comment. MFC uses it, for example, to ensure that wsock32 will be linked when you need to use Windows Sockets. The Sockcore.cpp source file contains the following statement:

Since it is mandatory for CProcess and CProcessList to link with psapi.lib and ntdll.lib, instead of adding these files to the project workspace, we can tell the linker to do it via a #pragma directive:

Since we work in a robust and documented way, it would be good to say, during compilation, that our class needs these files. Therefore, if someone else wants to reuse our code, he will not forget to get the corresponding .lib files. In order to tell the compiler to display a nice message during code building, you use another pragma called message:

The file psapi.lib can be found in the Samples folder on the MSDN library setup disk. However the file ntdll.lib is not provided by Visual C++, nor is it on the MSDN library disks, but it can be loaded from the Wrox web site. If you do not load these files into your project folder, you will get linker errors:

You note on this snapshot that the message is displayed at compile time and therefore before the link process even if you have written the #pragma message() after the #pragma comment(lib) in your code. It is a good habit to give the name of the file where the pragma message has been written, or else if you fail to do so, when error occurs later on, you are doomed to search your source code for the pragma string.

As we have stated earlier, a CProcessList object is responsible for taking a snapshot of running processes via Refresh(). Once the snapshot is taken, we can get each process description with GetFirst()/GetNext() which returns a CProcess object. Finally, for a given CProcess, it is easy to list each module it has loaded with GetFirst()/GetNext(), both of which return a CModule.

Our CAplView and CParentView classes both need to enumerate the running processes and the CModuleView class will need to know how to list every module loaded by the current process selected in CParentView or CAplView.

As we have seen in Chapters 13 and 16, the application data are stored by the document which provides its associated view with a simple programming interface of public methods. The document keeps for itself a protected CProcessList object and offers a GetProcessList() method to its views in order to access the low level system data. CProcessList has the responsibility to provide a high level access to the process list. Add this Get…() method and its associated protected data member to AplDoc.h:

Include this directive in AplDoc.h to let CAplDoc know of the CProcessList class.

In this way, if a view needs to enumerate the process list, it just needs to retrieve a CProcessList reference using its document GetProcessList() method, and get each process back in a GetFirst()/GetNext() loop:

Once a process object has been created, its description is available through its Get…() access methods. In order to list the loaded modules, a CModuleList object is retrieved by GetModuleList(). Again, you can use a GetFirst()/GetNext() sequence to get a CModule object for every loaded module, whose own Get…() access methods provide access to its description.

Another solution would be to let the document hide both process and module list objects behind a set of enumerator methods, which only provide CProcess and CModule lists. The main benefit of this is to hide the CProcessList and CModuleList from the views, since the document will provide the same kind of enumerator interface via GetFirstProcess()/GetNextProcess() and GetFirstModule()/GetNextModule().

The major drawback of such a relationship is to bind the view classes to a particular document class. If you wish to reuse your process and module views, you are forced into copying and pasting the GetFirst…()/GetNext…() code from the CAplDoc class into your new document class. With the chosen solution, shown below, your views only need to know the high level wrapper classes CProcessList, CProcess and CModuleList.

Note that User Interface and Data Wrapper layers have been introduced. We are now ready to describe, in detail, how the three views are filled. Finally, we will use the UpdateAllViews() method of our document to synchronize each view content and selection with their OnUpdate()methods.

Before leaving the document, we will answer a question that might have occured to you by now: when is the process list initialized? The answer is in the OnNewDocument() method which is called by the MFC framework by ProcessShellCommand(), from within InitInstance().

Delete the default AppWizard implementation of OnNewDocument():

Another interesting feature of MFC framework is its call of OnNewDocument() when an ID_FILE_NEW command is received. This is the reason why we have renamed the File New menu item and toolbar button as Refresh.

Therefore, if you try to refresh APL using the menu File | Refresh, the toolbar button or the F5 shortcut, you may be surprised to discover that a refresh occurs, and we have done nothing to achieve this behavior — the MFC framework has done the job for us. We have thus achieved one of our project objectives (#5, refreshing the screen output). We should now begin to think about filling our APL views using the process list.

We have already used OnInitialUpdate() to insert some test code to fill CAplView (during our development of the CListView class). It is now time to insert real code:

We will call the protected helper FillList(). Add it just under OnNeedText():

Next, write the following code in AplView.cpp for its implementation:

Before adding any item to the list, we have to empty it. In addition to DeleteAllItems(), note the insertion of the following line:

We now add m_ProcessIndex as a CTypedPtrMap<CMapPtrToPtr, DWORD, int> protected member:

Don't be afraid — its role will be explained very soon. Next, we get a reference to the process list stored in the document. It is now possible to enumerate the processes. We are using the GetFirst()/GetNext() methods of CProcessList to get each process. As you can see, a for loop is perfect for this kind of enumeration.

As we have explained earlier, we are using InsertItem() as add an item to the list view. We don't set each part of a process description to define every subitem for each item. Instead, we ask the list to call us whenever it needs to display the content of each column. In order to be sure to have the description of the process associated to a line, we pass the process pointer pProcess as lParam to the inserted item:

Since lParam will be given back to the notification handler OnGetDispInfo(), we just have to cast it into a CProcess* to retrieve the content for each column in OnNeedText().

Even if an item has been inserted, we still have cross-reference work to do. By associating a CProcess* to an item, it is easy to get the process description for a given line. However, the opposite is not true. Why would this be so important? We have already talked about the need to synchronize CParentView with CAplView and vice versa. When the user selects a process in the left pane tree view, we want the corresponding line in CAplView to auto-select. Similarly, when a process gets selected in the right pane CAplView, the same process should be visible and selected in the left CParentView pane.

Finally, we select the first item in the list view. We will go back later to the mechanism needed to synchronize the selection between CAplView and CParentView without looping forever.

As we are using the notification mechanism introduced earlier, so we have to implement OnNeedText(). Here is the source code:

We rely on the Get…() methods provided by CProcess to build the string which will be displayed in each column. However, the user interface layer may decide to represent information in a different way than the raw data returned by the data layer, for example, the content of the window column depends on whether the window has a title or not. The memory consumption is another good example — raw data is given in bytes and we want to the user to see the output kilobytes instead. (You can also offer the user to define his or her own choice through options: in bytes or in kilobytes.)

The filling of CParentView is the most complicated algorithm in our APL application. The reason is simple: Windows NT does not give us the tree of spawned processes. We have to rebuild it from the list of processes and their parents.

Let's take an example to help you understand the problem. Imagine you have launched Visual Studio by clicking its icon on the Desktop. After having loaded APL, you decide to debug Advanced Process List and you start it using F5. In CAplView, you would get the following list: