Tree View Control

The present invention relates generally to data processing systems and, more particularly, to displaying items in a hierarchical fashion in a data processing system.

In conventional systems, if application programs wish to display a hierarchical list of items, they must provide the code and data structures for displaying the list. This task can prove to be quite time-consuming and difficult. Unfortunately, conventional operating systems do not afford any relief as they do not provide support for applications to display such a hierarchical list of items.

The above described difficulties are overcome by the present invention. In accordance with a first aspect of the present invention, a method is practiced in a computer system that has an output device and a processor for running a first application program. In accordance with this method, a child window control is provided as a system resource. This child window control may be used by one or more application programs to display a list of items as a hierarchical tree on the output device. The child window control may support the hierarchical tree of items being expandable to show additional levels of items, and/or collapsible to hide levels of items.

In accordance with a second aspect of the present invention, a hierarchical tree of items, having at least two levels, is displayed on an output device. In response to a user using an input device, one of the items that is displayed in the hierarchical tree of items is selected. A visual cue may be provided for identifying the selected item. The hierarchical tree of items may be expanded or collapsed or the selection may remain constant so that the expansion or contraction does not affect which item is currently selected.

In accordance with another aspect of the present invention, a method is practiced wherein the computer system is a storage that holds an application program and code for managing a window that displays a hierarchical tree of items. In accordance with this method, a callback function for obtaining display information for one of the items displayed in the hierarchical tree of items is registered with an application program. The callback function is then called from code for managing a window to obtain display information for selecting one of the items in the hierarchical tree to display the item as part of the hierarchical tree that is visible in the window.

In accordance with a further aspect of the present invention, a hierarchical tree of items is displayed in a window on an output device. Each item in the hierarchical tree has a label that is displayed for the item. A mechanism for in-place editing is used to enable the user to perform in-place editing of the label of one of the items in the hierarchical tree.

In accordance with an additional aspect of the invention, the computer system includes an output device and a storage device. The storage device holds the first application program and code for a child window control. The child window control is a system resource that may be used by the first application program to display a list of items as a hierarchical tree of items. The hierarchical tree of items has at least two levels of items. The computer system also includes a processor for running the first application program and the code for the child window control to display the list of items as the hierarchical tree on the output device.

The preferred embodiment of the present invention will be described in more detail below with reference to the following drawings.

FIG. 1 is a block diagram of a computer system that is suitable for practicing the preferred embodiment of the present invention.

FIG. 2 is an example illustrating use of a tree view control in accordance with the preferred embodiment of the present invention.

FIG. 3 is a block diagram showing a programmatic representation of a tree view control in accordance with the preferred embodiment of the present invention.

FIG. 4 is a flow chart illustrating the steps that are performed to create a tree view control in accordance with the preferred embodiment of the present invention.

FIG. 5 is a flow chart illustrating the steps that are performed to insert an item into a tree view control in the preferred embodiment of the present invention.

FIG. 6 is a flow chart illustrating the steps that are performed to establish styles for a tree view control in the preferred embodiment of the present invention.

FIGS. 7A, 7B, and 7C illustrate different styles that are available for tree view controls in the preferred embodiment of the present invention.

FIG. 8 is a flow chart illustrating the steps that are performed to facilitate in-place editing of item labels in the preferred embodiment of the present invention.

FIG. 9 is an example of a tree view control that illustrates in-place editing of an item label in the preferred embodiment of the present invention.

FIG. 10 is a flow chart illustrating the steps that are performed to use notifications in the preferred embodiment in the present invention.

FIG. 11 is a flow chart illustrating the steps that are performed to use tree view messages in accordance with the preferred embodiment of the present invention.

FIG. 12 is a flow chart illustrating the steps that are performed to defer evaluation of an item until needed in accordance with the preferred embodiment of the present invention.

The preferred embodiment of the present invention provides a tree view control that is part of an operating system. The tree view control enables programs to display a hierarchical list of items in a window. The tree view control is a child window control that is available for application programs to use and eliminates the need to provide customized code to display data items in a hierarchical fashion. The tree view control provides the ability to expand or contract the tree of items that is shown to a user. This mechanism for expanding or contracting the tree is independent of a currently selected item in the tree. The labels associated with items may be edited in place. Furthermore, optimization mechanisms are provided within the tree view control to defer evaluation of information until needed so as to decrease memory requirements.

FIG. 1 is a block diagram of a computer system 10 that is suitable for practicing the preferred embodiment of the present invention. Those skilled in the art will appreciate that the computer system 10 shown in FIG. 1 is intended to be merely illustrative and that the present invention may also be practiced in other computer systems that have different configurations.

The computer system 10 of FIG. 1 includes a central processing unit (CPU) 12 that is coupled to a video display 14, a keyboard 20, and a mouse 22. The CPU 12 has access to a primary memory 16 and a secondary memory 18. The primary memory 16 may be realized as a number of different types of memory devices, including RAM devices, ROM devices, EPROM devices or EEPROM devices. The secondary memory 18 may be of any of a number of different secondary storage devices, including a hard disk device. Primary memory 16 holds a copy of an operating system 24. For purposes of discussion below, it will be assumed that the operating system 24 is the "MICROSOFT" WINDOWS 95 operating system from Microsoft Corporation of Redmond, Wash. The operating system 24 includes a dynamic link library (DLL) 26 that contains code structures and messages for implementing the tree view control. The DLL 26 may also include code for implementing additional controls. Those skilled in the art will appreciate that the present invention need not be implemented through a DLL and also need not be implemented as part of an operating system, but rather may be implemented as a separate system resource. The primary memory 16 also holds one or more application programs 28.

FIG. 2 shows an example of a tree view control 30. The tree view control 30 is manifested as a window within a parent window 31. As mentioned above, the tree view control is a child window control. As such, the tree view control sends notification messages to its parent window when events, like user input, occur within the tree view control. The tree view control 30 displays a hierarchical view of items 32. The items are organized as a tree. In the example shown in FIG. 2, the "Desktop" item 34 is the root of the tree and includes children items "My Computer" 36, "Network Neighborhood" 38, and "Recycle Bin" 40. The "My Computer" item 36 includes a number of children items (which are also grandchildren of the "Desktop" item 34). Thus, in this example, the items are displayed as a tree having multiple levels. As will be described in more detail below, the items 32 are also stored as a tree that is part of the tree view control.

As shown in FIG. 3, from a programming perspective, a tree view control 42 may be viewed as including a list of items 44 and code 46 for displaying and manipulating the items 44. The items 44 and the code 46 will be described in more detail below.

Each window displayed on the video display 14 has an associated window procedure that processes messages that are destined for the window. The operating system 24 supports the notion of a window class that identifies the window procedure for processing messages for a window of that class. The operating system 24 defines a special window class, WC.sub.-- TREEVIEW, for tree view controls. In order to create a tree view control like that shown in FIG. 2, a programmer follows the steps shown in the flowchart of FIG. 4. In particular, a programmer creates a window of the WC.sub.-- TREEVIEW window class by calling the CreateWindowEx() function that is provided by the operating system 24 (step 48 in FIG. 4). The CreatewindowEx() function is defined as part of the "MICROSOFT" "WIN32" API to be a function that creates windows with an extended style. The tree of items to be displayed by the tree view control must then be populated (step 50 in FIG. 4). In other words, items must be added to the tree view control so that they are properly added as part of the tree of items displayed by the tree view control.

Items are added, removed, and otherwise manipulated by sending messages to the tree view control. FIG. 5 is a flowchart of the steps that are performed to add an item to the tree view control. A TVM.sub.-- INSERTITEM message is sent to the tree view control to insert an item into the tree displayed by the control (step 52 in FIG. 5). A pointer to an TV.sub.-- INSERTSTRUCT data structure is passed as part of this message to the tree view control. The TV.sub.-- INSERTSTRUCT data structure has the following form (in C++):

This data structure includes a hParent field that holds a handle (i.e., a unique identifier) to a parent item in the tree. The parent item is the parent in the tree hierarchy of the item that is to be added. If the item to be added is a root of the tree, the item to be added has no parent, and the handle assumes a special value that designates the item as the root of the tree. The hInsertAfter field of TV.sub.-- INSERTSTRUCT holds the handle of an item after which the new item is to be inserted in the list of items 44 (FIG. 3). This field allows the system to know where to insert the item in the tree. The final field of the structure holds a data structure for the item to be added. This data structure is of the TV.sub.-- ITEM data type.

The TV.sub.-- ITEM data type holds information about an item and data structures of these types are stored in primary memory 16 (FIG. 1) and/or secondary memory 15 as items 44 (FIG. 3). This data structure is of the following format:

The "mask" field of this structure holds an array of flags that indicates which of the other fields in the data structure contain valid data or are to be filled in with data. The "state" field specifies a current state of the item. Possible states that an item may assume will be described in more detail below. The "stateMask" field holds a bit mask that identifies which of the states are valid states for the associated item. The "pszText" field holds a pointer to a location that contains text associated with the item. This field holds the text that is displayed in the label of the item. The "cchTextMax" field holds the size of the buffer that is pointed to by the pszText field.

The "iImage" field holds an index to an icon associated with the item and which is to be displayed in the tree view control beside the text for the item when the item is not selected. The index identifies the icon within an image list. The "iSelectedImage" field holds an index to a selected icon image within the image list that is displayed when the item is selected. If this value is null, the image identified by the "iImage" field is shown both when the item is selected and when the item is not selected. The "cChildren" field holds a value that specifies the number of children that are associated with the item.

Given the information contained within the TVM.sub.-- INSERTITEM message, the tree view control knows where to insert the item and possesses the requisite data for inserting the item into the tree. Hence, in step 54 of FIG. 5, the tree view control adds the item to the tree.

As was discussed above, each item within the tree has associated state information. This state information may identify whether an item has been selected by a user, whether an item has been expanded to show its children in the tree view or other state information about an item. The possible states for items include the following:

As mentioned above, an icon associated with items may be stored in image lists. Image lists are described in more detail in a copending application entitled "System Provided Child Window Controls," Ser. No. 08/355,410, filed Dec. 15, 1994 . Each item in the tree view control may have a pair of bit map images associated with it. In general, only one of the images appears at a time on the left-hand side of an item's label. In some instances, more than one image may be displayed. In particular, one image is displayed when the item is selected, and the other image is displayed when the item is not selected. For example, a folder item might display an open folder when it is selected and a closed folder when it is not selected.

A tree view control has different styles to govern aspects of the appearance of the tree view control. The initial style of a tree view control is set when the tree view control is created (step 56 in FIG. 6). The style of the tree view control may be changed by calling the SetWindowLongo() function, as defined in the "MICROSOFT" "WIN32" API (step 58 in FIG. 6).

In order to fully appreciate the implications of the different styles, it is perhaps best to examine a few examples of tree view controls wherein the styles are shown. FIG. 7A shows a small tree of items that is displayed as part of a tree view control 57. The tree of items includes folders 59, 60, 62, and 64. The "sales" folder 59 is the root of the tree, and the "1994" folder 60 is on the next level of the tree hierarchy, as indicated by the indentation. The "1994" folder 60 includes children folders "March" 62 and "April" 64. The representation of the tree view control 57 shown in FIG. 7A does not have any style settings set.

The TVS.sub.-- HASLINES style may be set to enhance the graphic representation of a tree view control hierarchy by drawings lines that link child items to the corresponding parent item. It should be noted that this style setting does not link items at the root of the tree view. In order to link items at the root of the tree view, the TVS.sub.-- LINESATROOT style must be set. FIG. 7B shows an example of the tree view of FIG. 7A with the TVS.sub.-- HASLINES and the TVS.sub.-- LINESATROOT styles set. Lines 66 are added by setting the TVS.sub.-- HASLINES style, and lines 68 are added by setting the TVS.sub.-- LINESATROOT style.

The style of the tree view hierarchy may also be further embellished by setting the TVS.sub.-- HASBUTTONS style that adds a button to the left side of each parent item. A "+" button may be displayed beside a parent item so that a user may click on the button to expand an item to show its children, and a "-" button may be displayed so that a user may click on the button to collapse an expanded item (so that its children are no longer displayed). FIG. 7C shows an example of the tree of FIGS. 7A and 7B, wherein "+" buttons 70 and "-" button 72 have been added (assuming that folders 62 and 64 may be further expanded). The mechanism for expanding and collapsing the tree is independent of the selection mechanism that is used to select tree items. As such, the tree may be expanded and collapsed without changing the current selection.

A user may incrementally explore the tree shown in tree view using the "+" buttons and "-" buttons and by double-clicking on items. Moreover, the "*" key or the keyboard may be used to fully expand a sub-tree.

An additional style, the TVS.sub.-- EDITLABELS style is provided to make it possible for the user to edit the labels of tree view items. FIG. 8 is a flowchart illustrating the steps that are performed to edit the label of a tree view item. The editing of the label of a tree view item may be initiated by either clicking on the label of the item with a mouse (step 84) or by an application sending a TVM.sub.-- EDITLABEL message to the tree view control (step 86). The tree view control informs its parent window that editing has begun by sending a TVN.sub.-- BEGINLABELEDIT notification (step 87). The parent window may refuse the editing if it wishes, so that no edits are accepted. The label may then be edited by simply typing in a new label for the item or by providing a new value for the label (step 88). When editing is complete, the tree view control sends a TVN.sub.-- ENDEDITLABEL notification to its parent window to inform the parent that editing of the label is complete (step 89). FIG. 9 shows an example where the label 90 for an item has been changed from "Lex 27" to "Owl." Once the editing is complete the label assumes the newly edited value.

As has been discussed above, a tree view control communicates with its parent via notifications that are encapsulated into WM.sub.-- NOTIFY window messages. A number of these notifications relate to drag-and-drop operations. The TVN.sub.-- BEGINDRAG notifications is sent to signal the start of a drag-and-drop operation using a left mouse button. The TVN.sub.-- BEGINRDRAG notification is sent to signal the start of a drag-and-drop operation using the right mouse button.

Notifications are also provided to perform activities relative to displaying items in a tree view control. The TVN.sub.-- GETDISPINFO notification requests that information required to display an item be obtained for a tree view control. The TVN.sub.-- SETDISPINFO notification notifies a parent that it must update the information that is maintained for an item. These notifications are also encapsulated in WM.sub.-- NOTIFY window messages.

Other notifications include the TVN.sub.-- DELETEITEM notification that signals the deletion of a specific item within the tree view control. The TVN.sub.-- ITEMEXPANDED notification signals that a parent's list of child items has been either expanded or collapsed. The TVN.sub.-- ITEMEXPANDING notification signals that the list of child items for a parent is about to be expanded or collapsed. The TVN.sub.-- KEYDOWN notification signals a keyboard event and identifies the key. A failure reply from the parent in response to TVN-KEYDOWN tells the tree view control to not process the key. The TVN.sub.-- SELCHANGED notification signals that a selection has been changed from one item to another. Lastly, the TVN.sub.-- SELCHANGING notification signals that the selection is about to be changed from one item to another. The TVN.sub.-- ENDLABELEDIT and TVN.sub.-- BEGINLABELEDIT notifications have been discussed above.

It should be appreciated that the notifications give the parent an opportunity to refuse an action. For example, upon receiving a TVN-SELCHANGING message, a parent may refuse and abort the change.

FIG. 10 is a flowchart showing the basic steps performed to utilize notifications within the preferred embodiment of the present invention. In particular, the tree view control sends a notification to the parent to inform parent of events (step 92). The parent then processes the notification as it sees fit and may perform activities in response to the notification (step 94). In some instances, no further action is taken. The notification is sent purely to notify.

A parent application sends messages to add items and to control the appearance behavior of a tree view control. Each message has a corresponding macro that may be executed. The macro results in the corresponding message being sent. Amongst these messages are standard window messages and messages that are particularly directed to the new controls. The latter type of messages include the TVM.sub.-- DELETEITEM message that requests a specified item (identified by a parameter) be deleted from a tree view window. The TVM.sub.-- EDITLABEL message is sent to begin in-place editing of a specified item's label. The item is identified by passing its handle as a parameter in the message or in the macro call.

The TVM.sub.-- EXPAND message is sent to expand or collapse a list of child items associated with a parent item. A handle to the parent item is passed in the message or is a parameter to the macro call. When expansion is about to begin the TVM.sub.-- ITEMEXPANDING notification is sent and when the expansion is completed, the TVM.sub.-- ITEMEXPANDED notification is sent to the parent window. Another of the parameters identifies whether the parent item is to be expanded or collapsed.

The TVM.sub.-- GETIMAGELIST message is sent to get the handle of the image list that is associated with the tree view control. The index of a particular tree item is sent as a parameter. The TVM.sub.-- GETITEM message is sent to get information about a specified tree view item. The TVM.sub.-- GETNEXTITEM message is sent to get the next tree view item based upon a specified code. The code may specify whether to get the currently selected item, the first child item, the item that is a target of a drag-and-drop operation, the first visible item, the next sibling item, the next visible item, the parent of the item, the previous item, the first visible item that precedes a given item or the first child item of the root item.

The TVM.sub.-- INSERTITEM message is sent to insert a new item into a tree view control. One of the parameters passed in this message or in the macro call is the identification of a structure containing item attributes. The TVM.sub.-- SELECTITEM message is sent to select a given tree view item, scroll the item into view, and redraw the item. One of the parameters passed in this message or in the macro call is a handle for the tree view item that is to be redrawn. Another of the parameters is a code that identifies the action with regard to a selection should take. A first code sets a selection to the item that is identified by the other parameter. If the item is a child of a collapsed parent item, the parent's list of children is expanded to reveal the item. The code may also indicate that the item is to be redrawn in the style that is used to indicate that it is a target of a drag-and-drop operation. Lastly, the code may indicate that the tree view is to be scrolled vertically so that the item is the first visible item in the portion of the tree that is displayed in the tree view control window.

The TVM.sub.-- SETITEM message is sent to set the attributes of a tree view item. Those skilled in the art will appreciate that other tree view messages may be used to effect the activity of the tree view control. FIG. 11 is a flowchart illustrating the basic steps that are performed when such messages are to be utilized. The parent application sends the message to the tree view control or the corresponding macro is called (step 96) The tree view control then acts on the message or macro call as appropriate (step 98).

The preferred embodiment of the present invention provides an optimization that may be used to minimize the amount of memory used by a tree view control. In general, a tree view control allocates memory for storing each item in a tree. Since each tree view item may have an associated label, a large amount of memory may be occupied by the storage of the items to be displayed by a tree view control. If an application already has a copy of the strings that are to be used as labels, the preferred embodiment of the present invention provides a vehicle for avoiding the extra memory allocation. FIG. 12 is a flowchart showing the steps that may be performed to avoid the extra memory allocation. Whenever the tree view control needs such text, it sends a TVN.sub.-- GETDISPINFO notification to the parent window with the address of a TV.sub.-- DISPINFO data structure (step 102). The TV.sub.-- DISPINFO data structure holds information that is needed to display an item in the tree view control window. Upon receiving this notification, the parent fills in the text for the label (step 104); thus avoiding the need for allocating extra memory for the label.

While the present invention has been described with reference to a preferred embodiment thereof, those skilled in the art will appreciate that various changes in form or detail may be made without departing from the intended scope of the present invention as defined in the appended claims.

A more detailed technical explanation of a tree view controls is provided in the attached appendix. ##SPC1##