System Provided Child Window Controls

The present invention relates generally to data processing systems and, more particularly, to child window controls.

The "MICROSOFT" WINDOWS, Version 3.1, operating system sold by Microsoft Corporation of Redmond, Wash., provides application developers with child window controls that they may integrate into their applications. Unfortunately, the number of controls that are provided by the operating system and the range of functionality provided by the controls are not sufficient for all applications. As a result, application developers have been forced to create their own child window controls.

In accordance with a first aspect of the present invention, a method is practiced in a computer system that has an input device, a video display and a processor that runs at least one application program. In accordance with the method of this aspect of the present invention, code for implementing a new child window control is provided as a system resource that the application program may use. The code may be for implementing a header bar control that is a multi-piece child window control that displays headers as a bar. Alternatively, the code may be for implementing a tab control. The tab control displays tabs for differentiating pages that are to be displayed by the application program. Furthermore, the code may be for a hot key control that allows a user to edit and view a key combination that constitutes a hot key. The hot key invokes activity in the application program. A system resource is then used to display the associated control.

In accordance with another aspect of the present invention, an image list data type is provided for an image list. Each image list is an indexed list of bitmaps. An image list is provided that is of the image list data type, and an image in the provided image list is displayed on the video display.

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 a diagram illustrating an example header bar control that is generated in accordance with the preferred embodiment of the present invention.

FIG. 3 is a flowchart illustrating the steps that are performed to use a header bar control in the preferred embodiment of the present invention.

FIG. 4 is a flowchart illustrating the steps that are performed to add items to a header bar control in accordance with the preferred embodiment of the present invention.

FIG. 5 is a flowchart illustrating the steps that are performed to delete items from a header bar control in accordance with the preferred embodiment of the present invention.

FIG. 6 is a flowchart illustrating the steps that are performed to change items in a header bar control in the preferred embodiment of the present invention.

FIG. 7 is a diagram that illustrates the use of a hot key control in accordance with the preferred embodiment of the present invention.

FIG. 8 is a flowchart illustrating the steps that are performed to create a hot key control in accordance with the preferred embodiment of the present invention.

FIG. 9 is a flowchart illustrating the steps that are performed to set rules regarding invalid key combinations and to provide modifier combinations for hot key controls in the preferred embodiment of the present invention.

FIG. 10 is a flowchart illustrating the steps that are performed to set a key combination for a hot key control in accordance with the preferred embodiment of the present invention.

FIG. 11 is a diagram illustrating tabs that are provided by a tab control in the preferred embodiment of the present invention.

FIG. 12 is a flowchart illustrating the steps that are performed to create a tab control in accordance with the preferred embodiment of the present invention.

FIG. 13 is a flowchart illustrating the steps that are performed to add items to a tab control in the preferred embodiment of the present invention.

FIG. 14 is a diagram illustrating the TCS.sub.-- BUTTONS style for a tab control in accordance with the preferred embodiment of the present invention.

FIG. 15 is a flowchart illustrating the steps that are performed when a user selects a tab in a tab control per the preferred embodiment of the present invention.

FIG. 16 is a flowchart illustrating the steps that are performed to use an image list with a tab control in accordance with the preferred embodiment of the present invention.

FIG. 17 is a flowchart illustrating the steps that are performed to adjust the size and position of a tab control in accordance with the preferred embodiment of the present invention.

FIG. 18 is a flowchart illustrating the steps that are performed to delete an item from the tab control in accordance with the preferred embodiment of the present invention.

FIG. 19 illustrates the steps that are performed to create an image list in accordance with the preferred embodiment of the present invention.

FIG. 20 is a flowchart illustrating the steps that are performed to add objects to an image list in accordance with the preferred embodiment of the present invention.

FIG. 21 is a flowchart illustrating the steps that are performed to remove objects from an image list in accordance with the preferred embodiment of the present invention.

FIG. 22 is a flowchart illustrating the sequence of function calls that are performed to draw an image during a drag-and-drop operation in accordance with the preferred embodiment of the present invention.

The preferred embodiment of the present invention provides new child window controls as part of an operating system. These child window controls may be utilized by application programs that run on the operating system. The new child window controls include a header bar control, a hot key control and tab controls. These new child window controls will be described in more detail below.

FIG. 1 is a block diagram of a computer system that is suitable for practicing the preferred embodiment of the present invention. Those skilled in the art will appreciate the computer system 10 shown in FIG. 1 is intended to be merely illustrative and that the present invention may 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 has access to a number of peripheral devices, including a mouse 14, a keyboard 16 and a video display 18. The CPU also has access to a memory 20 and a secondary storage 22. The secondary storage 22 may be any of a number of different types of secondary storage devices, including a hard disk storage device. Memory 16 holds a copy of an operating system 24. The new child window controls provided by the preferred embodiment of the present invention are implemented as part of the operating system in a controls dynamic link library (DLL) 26 that contains code, structures and messages for implementing the new child window controls. Those skilled in the art will appreciate that the controls DLL 26 may also include the necessary code, structures and messages for implementing additional child window controls. Those skilled in the art will also appreciate that the present invention need not be implemented through a DLL. Further, the present invention need not be implemented as part of an operating system but rather may be implemented as a separate system resource. The memory 16 also holds one or more application programs 28.

Child window controls are child windows that reside within parent windows. The child windows send notification messages to the parent windows when events occur. For example, when user input is received in a child window, the child window sends the input to the parent window. One of the primary uses of child window controls is to process mouse and keyboard messages so that the child window acts as a kind of input device for the parent window.

For purposes of the discussion below, it is assumed that the operating system 24 is the "MICROSOFT" WINDOWS 95 operating system, sold by Microsoft Corporation of Redmond, Wash. This operating system 24 is a windows-based operating system. Windows are created based upon a window class. The window class identifies a window procedure that processes messages that are sent to the window. The operating system 24 supports a RegisterClass() function that enables an application to register a window class. The window procedure for a window is the function that receives and processes messages that are sent to the window. The operating system 24 is a message-based operating system such that operations are achieved by passing messages between windows. As will become more apparent in the discussion below, applications 28 communicate with child window controls by sending the child window controls messages and by receiving notifications from the child window controls.

An application 28 utilizes a child window control by incorporating a child window control into a parent window that the application provides. The controls DLL 26 is a library that has functions which may be called by the application programs to control the appearance of the child window control and to perform the actions with respect to the child window control.

A header bar control is a window that is typically positioned as a header for columns or rows of information. Typically, a header bar is a multi-piece window, wherein each piece includes text and may include an image. FIG. 2 shows an example of a header bar control 32 for a window 30 that contains a listing of files in a directory. The header bar control is divided into a name part 34, a size part 36, a type part 38 and a modified part 40. The header bar provides headers for the columns that are positioned beneath the pieces of the header bar. The example shown in FIG. 2 depicts a horizontally-oriented header bar. Those skilled in the art will appreciate that header bars may also be oriented vertically to serve as headers for rows.

FIG. 3 is a flowchart that shows the steps that are performed to create and display a header bar control. Initially, an application creates a window of the WC.sub.-- HEADER windows class (step 42). This window class is the predefined windows class that is registered for header bar controls by the controls DLL 26 (FIG. 1). The control then must be populated with items (step 44 in FIG. 3). This achieved by adding items to the header bar control.

FIG. 4 shows in more detail how items are added to the header bar control. In particular, a predefined message, HDM.sub.-- INSERTITEM message is sent to the window procedure that is responsible for the header bar control. Alternatively, a macro function may be called to achieve the same effect as the message. In either case, the address to an HD.sub.-- ITEM structure is passed as a parameter (step 50 in FIG. 4). This structure has the following format.

The mask field of the HD.sub.-- ITEM structure holds flags that indicate which of the other field in the structure contain valid data. The cxy field holds a value that specifies the width or height of the item. If the header bar is oriented horizontally, the cxy field holds a value that specifies the width of the item. On the other hand, if the header bar control is oriented vertically, the cxy field holds a value that specifies the height of the item. The pszText field holds an address to the memory location that holds the string that is to be displayed in the piece of the header bar that is associated with the item. The hbm field holds a handle to an optional bitmap that may be displayed for the item on the header bar. The cchTextMax identifies the length of the item string in characters. The item string was discussed above relative to the pszText field. The fmt field holds format flags that identify whether the contents of the item should be center aligned, left aligned or right aligned. It also specifies whether the item is a bitmap, string or owner drawn. Lastly, the lParam field is a field that is reserved for holding application defined item data.

Thus, in order to add an item, a HD.sub.-- ITEM structure is defined for an item and the address of the structure is passed in the HDM.sub.-- INSERT item message or in the corresponding macro call to the header bar control. The header bar control uses this information to add the item to the control (step 52 in FIG. 4).

In step 44 of FIG. 3, items are added to the header bar control by following the steps described above. For instance, for the example header bar shown in FIG. 2, a name item, a size item, a type item and a modified item must be added to the header bar control. Separate HD.sub.-- ITEM structures must be defined for each of these items. No optional bitmaps are displayed within the pieces of the header bar that are show in FIG. 2.

An application may specify styles for the header items. The HDS.sub.-- BUTTONS style makes each item in the header bar control look and behave as if it is a push button. Thus, the user may use the mouse 14 to push the various items shown on the header bar control. It is the responsibility of the application to determine what action to perform when a user clicks on one of the items in the header bar control. The header bar control merely informs the application that the item has been clicked on. The HDS.sub.-- HORZ style creates a header control with a horizontal orientation, whereas the HDS.sub.-- VERT style creates a header bar control with a vertical orientation.

In order to display the header bar control, the size and position of the header bar control must be determined. The application program sends in a HDM.sub.-- LAYOUT message to the header bar control or calls the corresponding macro and passes an address of an HD.sub.-- LAYOUT structure that contains the coordinates of the rectangle that the header control is to occupy. Further, a pointer to a window POS structure is passed by the message or macro call (step 46).

The HDMLAYOUT structure has the following format.

The prc field holds a pointer to a bounding rectangle structure that contains the coordinates of a rectangle in which the header control is to be drawn. The pwpos field holds a pointer to the WINDOWPOS structure. The WINDOWPOS structure is a standard structure defined by the operating system that defines where the window is to be positioned within a given bounding rectangle. Hence, in step 48, the header bar control is displayed using the HD.sub.-- LAYOUT and WINDOWPOS structures.

The above discussion has noted that items may be added to a header bar control. It should be appreciated that items may also deleted from header bar controls. FIG. 5 is a flowchart illustrating the steps that are performed to delete an item from the header bar control. An application sends a HDM.sub.-- DELETEITEM item message to the child window control or calls the corresponding macro (step 54 in FIG. 5). In response to receiving the message or the macro call, the child window control deletes the item so that it is no longer displayed.

An application may also change the values that are set for an item within a header bar control. In order to do this, an application sends an HDM.sub.-- SETITEM message to the header bar control or calls the corresponding macro (step 58). The HDM.sub.-- SETITEM message or the macro call includes a handle to the header bar control and an index of the item whose attributes are to be changed. The address of an HD.sub.-- ITEMSTRUCTURE is also passed. The mask field of this structure indicates which attributes are to be set. Other fields specify new attributes. The header bar control receives the message or the macro call and changes the item accordingly (step 60 in FIG. 6).

Individual items of the header control can be defined to be owner drawn items. To specify an item as an owner drawn item, the fmt format field should be set to specify that the item is to be owner drawn. When the header bar control must draw an owner drawn item, it sends a WM.sub.-- DRAWITEM message to the parent window. The message includes a parameter that identifies the header bar control and also includes a parameter to a structure that the parent window may use to draw the item.

As was discussed above, a header bar control sends a notification message to its parents when a user clicks on an item, double clicks on an item, drags an item divider, changes the attributes of an item. These notifications are sent as WM.sub.-- NOTIFY messages. The following is a list of notification messages and a brief description of them.

When a divider that separates items is being dragged, the header bar control sends an HDN.sub.-- TRACK notification message and redraws itself based upon where the user drops the border. Thus, a user may adjust the size of the item as the user sees fit.

The preferred embodiment of the present invention also provides hot key controls. A hot key control is a window that enables a user to create a hot key. A hot key is a key combination that the user may press to perform an action quickly. For example, a user may create a hot key that activates a window and brings the window to the top of the windows currently being displayed (i.e., to the top of the Z order). The hot key control displays a user's choice of a hot key combination and ensures that the user selects a valid hot key combination. FIG. 7 shows an example of a hot key control 62 that is displayed on a property sheet for a setup program. For the example shown in FIG. 7, the hot key combination is a control key + shift key + W key combination.

An application creates a hot key control by performing the steps illustrated in the flowchart of FIG. 8. Initially, an application program creates a window of the HOTKEY.sub.-- CLASS window class (step 66 in FIG. 8). The HOTKEY.sub.-- CLASS window class is registered by the controls DLL 26 (FIG. 1). The application may create a window of this class by calling the CreateWindowEx() function as defined by the "MICROSOFT" WIN32 API. This function returns a handle (i.e., a unique numerical identifier) to the hot key control.

The application may then desire to set some rules about invalid hot key combinations (step 68). Those skilled in the art will appreciate that this step is optional and at the discretion of the application. An application sets rules for invalid hot key combinations by performing the steps shown in the flowchart of FIG. 9. The application sends a HKM.sub.-- SETRULES message or calls a corresponding macro (step 72 in FIG. 9). The message or macro call contains two parameters. The first of these parameters is an array of flags that specifies invalid key combinations. This array of flags may be any combination of the following values.

The second parameter passed in the message or macro call is an array of flags that specify modifier key combinations that are to be used when the user enters an invalid combination. These flags can be a combination of any of the following values.

The modifier keys replace the invalid keys that are entered.

After the hot key control receives the HKM.sub.-- SETRULES message or the corresponding macro is called, the hot key control sets invalid hot key combinations and sets the appropriate modifier combination (step 74 in FIG. 9).

An application may also specify a default hot key combination that is to be used if the user does not provide a hot key combination (step 70 in FIG. 8). These default key combinations are provided by sending the HKM.sub.-- SETHOTKEY message or calling a corresponding macro. FIG. 10 is a flowchart illustrating the steps that are performed to set such hot key values (either default or otherwise). In step 76, the application sends the HKM.sub.-- SETHOTKEY message or calls the corresponding macro. This message includes two parameters. A first of the parameters specifies a virtual key code for the hot key. The second parameter specifies modifier flags that indicate keys which, when used in combination with the key defined by the first parameter, define a hot key combination. The hot key control uses these parameters to set the appropriate hot key combination value (step 78 in FIG. 10).

After a hot key combination has been established and a hot key control has been created, a WM.sub.-- SETHOTKEY windows message may be sent by an application to the operating system 24 to set up a hot key in the system. The virtual key code of the hot key is passed as a parameter to this message. Those skilled in the art will appreciate that this is merely an illustrative case and is not intended to be limiting of the present invention.

Whenever a user presses the hot key after the hot key has been set up in the system, a window of the application receives a WM.sub.-- SYSCOMMAND message that specifies the hot key virtual key code. This message causes the window to be activated and the application then responds to the hot key.

The preferred embodiment of the present invention also provides tab controls. Tab controls are child window controls that analogous to dividers like those found in a notebook or to labels found in a file cabinet. By using a tab control, an application program 28 may define multiple pages for the same area of a window or a dialog box. Each page includes a set of information or a group of controls that the application displays when the user selects the corresponding tab. FIG. 11 shows an example of tab controls 80 and 82 that are shown for property sheets. Tab control 80 is associated with and used to select property sheet page 84.

FIG. 12 is a flowchart illustrating the steps that are performed to create a tab control. First, an application program creates an instance of a window of the WC.sub.-- TABCONTROL window class. The application program may create a window of this class by calling the CreateWindow() function or the CreateWindowEx() function of the "MICROSOFT" WIN32 API. The application program then must populate the control with items (step 88). Each tab is associated with a corresponding item.

FIG. 13 is a flowchart illustrating the steps that are performed to add items to a tab control. An application may add an item to a tab control by sending a TCM.sub.-- INSERTITEM message or calling a corresponding macro (step 90 in FIG. 13). This message or the corresponding macro call includes a parameter that identifies a TC.sub.-- ITEM data structure that has the following format.

The mask field of the structure holds a value that specifies which fields are to be set. The lpReserved1 and lpReserved2 fields are not currently used. The pszText field holds a pointer to a memory location that holds a text string that is to be displayed on the corresponding tab. The cchTextMax field holds a value that specifies the size of the buffer that is pointed to by the pszText field. The iImage field is an index into a tab control image list or a value of -1 that specifies there is no image for the tab. Image lists will be described in more detail below, but for current purposes, it suffices to note that image lists contain an indexed list of images that are logically grouped together. The lParam field points to application defined data that is associated with the tab.

The tab control receives the message or macro call and the address of the associated TC.sub.-- ITEM structure. The tab control then adds the item (step 92 in FIG. 13). For example, tab control is shown in FIG. 11, separate items must be provided for the "TaskBarOptions" tab 80 and the "StartMenuPrograms" tab 82.

An application may control the characteristics of tab controls by specifying tab control styles. The following tab control styles are defined.

The TCS.sub.-- BUTTONS style may be selected so that the tabs appear like buttons. FIG. 14 shows an example wherein tabs 94 and 96 on the task bar appear like buttons. These buttons and the task bar are described in more detail in co-pending application entitled "Taskbar with Start Menu", Ser. No. 08/572,725, now U.S. Pat. No. 5,757,371 which is assigned to a common assignee with the present application and which was filed on even date herewith.

An application can specify that a tab receives the input focus when the tab is clicked on using the mouse 14 by specifying the TCS.sub.-- FOCUSONBUTTONDOWN style. An application may also specify that a tab never receives the input focus by using the TCS.sub.-- FOCUSNEVER style.

By default, a tab control displays all tabs in one row. If the tab control cannot display all the tabs at once, the tab control displays an up/down control so the user can scroll the additional tabs into view. An application can cause a tab control to display multiple rows of tabs by specifying the TCS.sub.-- MULTILINE style.

Tabs are generally left aligned within a row. An application may, however, specify the TCS.sub.-- RIGHTJUSTIFY style. A tab control automatically sizes each tab to fit its icon and label. To ensure that all tabs have the same width, an application may specify the TCS.sub.-- FIXEDWIDTH style. An application may assign a specific width and height by using the TCM.sub.-- SETITEMSIZE message. This message passes the width and height of a tab as a parameter.

Within each tab, the tab control centers any icon and labels the icon to the left of the label. An icon may be forced to the left, leaving the label centered, by specifying the TCS.sub.-- FORCEICONLEFT style. An application may left align both the icon and label by using the TCS.sub.-- FORCELABELLEFT style. An application may specify that the parent window draws tabs in the tab control by selecting the TCS.sub.-- OWNERDRAWFIXED style. Lastly, an application may specify that a tab control creates a tool tip control by specifying the TCS.sub.-- TOOLTIPS style.

FIG. 15 is a flowchart showing the steps that are performed when a user selects a tab. In step 100, the user selects the tab. Typically, the user selects a tab by positioning a mouse cursor to point at the tab and then clicking a designated mouse button on the mouse 14. In response to the selection, the tab control sends a TCN.sub.-- SELCHANGING notification message if the tab is different from the tab that currently has focus (step 102). The selection is then changed (step 104) and a TCN.sub.-- SELCHANGE notification message is sent to the application (step 106). The application processes the TCN.sub.-- SELCHANGE notification message to display the appropriate incoming page in the display area.

As was discussed above, each tab may have an icon associated with it. This icon is specified by an index into an image list that is associated with the tab control. FIG. 16 is a flowchart of the steps that are performed to associate an image list with a tab control. Initially, the application creates an image list using functions provided by the operating system 24, which will be described in more detail below (step 108). The image list is then assigned to the tab control by sending the TCM.sub.-- SETIMAGELIST message from the application to the tab control (step 110).

The size and position of each tab in a tab control may be manipulated. FIG. 17 shows the steps that are performed to manipulate the size and position of the tab control. A message is sent to the tab control regarding size and position (step 112). The tab control then responds to this message to manipulate the size or position of the tab (step 114). For example, as was discussed above, the exact width and height of tabs may be set by sending the TCM.sub.-- SETITEMSIZE message from the application to the tab control. The thickness of the margin for tab controls may be set by sending a TCM.sub.-- SETPADDING message from the application to the tab control. The horizontal and vertical padding are passed as parameters to this message. In addition, the current bounding rectangle for a tab may be determined by sending the TCM.sub.-- GETITEMRECT message to the tab control.

As was discussed above relative to the TCS.sub.-- OWNERDRAWFIXED style, a tab control may be established that requires the parent window to print tabs. When a tab control needs to paint a tab and this style is set, the tab control sends a WM.sub.-- DRAWITEM windows message. One of the parameters that this message specifies is a data structure that contains the index of the tab, its bounding rectangle and a device context in which to draw the tab.

Tabs for tab controls may be deleted. FIG. 18 is a flowchart illustrating the steps that are performed to delete tabs. First, a delete message is sent from an application to a tab control (step 116 in FIG. 18). The message may be a TCM.sub.-- DELETEITEM message that includes an index to the item that is to be deleted or may be a TCM.sub.-- DELETEALLITEMS message for deleting all of the items in a tab control. The tab control receives these messages and then performs the requested deletions (step 118).

An application may adjust the window rectangle that corresponds to a tab control's display area by sending a TCM.sub.-- ADJUSTRECT message. This message passes the handle of a tab control as a parameter. A second parameter may assume a first value that indicates that a third parameter specifies a display rectangle and receives a corresponding window rectangle or, alternatively, specifies a window rectangle and receives a corresponding display area. The third parameter specifies the address of a RECT structure that specifies a given rectangle in which tab control is to be displayed.

A tab control notifies an application of mouse and keyboard events that occur on tabs that are provided by the tab control. The tab control notifies an application of a key event by sending a TCN.sub.-- KEYDOWN notification message that is sent in the form of a WM.sub.-- NOTIFY windows message and includes the address of a TC.sub.-- KEYDOWN structure. This structure includes a virtual key code for the key that was depressed.

As was discussed above, the preferred embodiment of the present invention supports the use of image lists. An image list is a collection of same-sized images that are individually referenceable by an index. All images in an image list are contained in the single wide bitmap in screen device format. An image list may also include a monochrome bitmap that contains masks used to draw images transparently. In particular, there are two types of image lists: non-masked and masked. A non-masked image list includes a color bitmap that contains one or more images. On the other hand, a masked image list includes two bitmaps of equal size. The first bitmap is a color bitmap that contains the images, whereas the second bitmap is a monochrome bitmap that contains a series of masks. When a masked image is drawn, the bits of the image are combined with the bits of the mask to produce transparent areas of the bitmap where a background color of the target device context shows through. In contrast, when a non-masked image is drawn, it is simply copied in the target device context and is drawn over existing background color of the device context.

Image lists are useful to display large sets of icons or bitmaps. As was discussed above, a single image list may contain the icons the bitmaps use for a number of tabs in a tab control. Likewise, image lists may be used in other applications wherein a number of icons or bitmaps are required. The operating system 24 provides a number of functions for displaying, managing and manipulating an image list. Code for these functions are provided in the controls DLL 26.

An application creates an image list by calling the ImageList.sub.-- Create() function provided by the operating system 24 (step 120 in FIG. 19). The parameters to this function call include the type of image list to be created, the dimension of each image in the image list and the number of images to be added to the list. For a non-masked image list, this function creates a single bitmap that is large enough to hold the specified number of images of the given dimensions. In such a case, the function creates a screen compatible device context and selects a bitmap for the device context. For a masked image list, the function creates two bitmaps and two screen compatible device contexts. The function selects the image bitmap for one device context and the masked bitmap for the other. If the function is successful, it returns a handle to the image list (step 122). This handle may be used as a parameter that is passed in other image list functions.

An application program can add bitmap images, icons or cursors to an image list. The operating system 24 provides a number of functions for adding different types of objects to image lists. In general, to add an object to an image list, the steps shown in the flowchart of FIG. 20 are performed. Initially, the application calls one of the functions for adding an object to the image list (step 124). The desired object is then added to the image list in response to the function call (step 126).

The ImageList.sub.-- Add() function facilitates the addition of bitmap images to an image list. An application passes handles for up to two bitmaps as a parameter to this function. For non-masked image lists, only one handle is passed; whereas for masked image lists, up to two handles may be passed. A first handle points to a first bitmap that contains one or more images to add to the image list bitmap. The second handle identifies a second bitmap that contains masks to be added to the mask bitmap. For masked image lists, the ImageList.sub.-- AddMask() function is provided to add bitmapped images to the masked image list.

Separate functions are provided for icons. In particular, the ImageList.sub.-- AddIcon() function adds an icon or cursor to an image list. If the image list is masked, this function adds the mask provided with the icon or cursor to the mask bitmap. In addition, an icon, based on an image and mask in an image list, may be used to create an icon by calling the ImageList.sub.-- ExtractIcon() function. This function returns the handle of the new icon.

The ImageList.sub.-- AddFromImageList() function copies an image from one image list to another. The image in both the image lists must be the same size for this function.

It should be appreciated that indexes are assigned to each image as it is added to an image list. The indexes are zero-based such that the first image in a list has an index of zero, and the next image has an index of one, and so forth.

Functions are also provided for removing objects from an image list. To remove an object from an image list, an application follows the steps shown in the flowchart of FIG. 21. First, the application calls the appropriate function to remove the object (step 128 in FIG. 21). In response to this function call, the operating system 24 removes the object from the image list (step 130). One such function is the ImageList.sub.-- Remove() function that removes a particular image from an image list. Images may also be removed from an image list and replace with substitute images by calling the ImageList.sub.-- Replace() function or the ImageList.sub.-- ReplaceIcon() function. The first of these functions replaces the image with a bitmapped image and mask, whereas the second of these functions replaces an image with an icon or a cursor.

The ImageList.sub.-- Merge() function merges two images and stores the new image in a new image list. The new image is created by drawing the second image transparently over the first image. The mask of the new image is the result that performing a logical OR operation on the bits of the mask for the two existing images.

The operating system 24 provides functions for drawing images on image lists. The ImageList.sub.-- Draw and ImageList.sub.-- Draw2() functions are provided to draw images from image lists. The first function simply displays an image list item to a device context, whereas the second function uses a specified drawing style (passed as a parameter) and blends the image with a specified color. The calling application passes the handle of an image list, an index to an image to be drawn, a handle of a destination device context, location within the device context and one or more drawing styles as parameters to these functions.

Every image list includes a list of images to use as overlay masks. An overlay mask is an image that is drawn transparently over another image. Up to four overlay masks may be specified per image list. Overlay images may be established by calling the ImageList.sub.-- SetOverlayImage() function.

The operation system 24 also includes functions for dragging an image in an image list on the video display 18. FIG. 22 is a flowchart showing the steps that are performed by an application during a drag-and-drop operation. An application calls the ImageList.sub.-- StartDrag() function to be a drag-and-drop operation in response to the user using an input device to drag an image (step 132). The ImageList.sub.-- StartDrag() function creates a new image by combining the image to be dragged with the current mouse cursor. As the image is dragged, the ImageList.sub.-- DragMove() function is called to display the image at a new location that coincides with the hot spot of the mouse cursor (step 134). At the end of the drag operation, the ImageList.sub.-- EndDrag() function is called.

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 and detail may be made without departing from the intended scope of the present invention as defined in the appended claims.

The controls of the preferred embodiment of the present invention are described in more detail in the attached appendix. ##SPC1##