Programming the Container Control - Part 1

Written by Larry Salomon Jr.

Introduction
The release of OS/2 2.0 was special in many ways; not the least was the inclusion of four new standard PM controls: the container, the notebook, the slider, and the value set. Without question, the most difficult of these to utilize fully is the container control. Its flexible design allowed for it to be used in a variety of fashions (which is no surprise when you look at its real-world counterpart) and provided a CUA 91 compliant interface without much additional work by the programmer. Unfortunately, the initial work that has to be done is significant and has daunted many developers.

This article begins a multi-part series on how to program the container and will describe the container control from a developer's perspective as well as introduce some of the basic programming concepts that can be used in you applications. For additional information, it is highly recommended that you acquire a copy of the Winter and Spring 1993 issues of the OS/2 Developer Magazine (produced by IBM Corp. and published by Miller Freeman Inc.). These two issues contain a single article each by the container control developers on how to use it and are both very informative.

A Bird's-Eye View
In "real-life" a container is something that you see everyday. Most people store foodstuffs in Tupperware containers. On many office desks, pens and pencils are stored in containers. In a filing cabinet, documents are stored in another container, although it is more widely known as a folder. Everywhere you look, there are containers being used; because of this, the CUA designers decided that the ability to store objects in a container was a very good thing; not only was it a familiar concept, but it was also already being used on another computer platform (the Macintosh) with extremely good results.

The container is exactly what you think it is. It allows an application to place "things" inside of it and these things can be viewed in one of five different ways. The term "thing" is used because the container does not restrict the application in the type of items stored. The five different views supported by the container are listed below: This month, we will only employ the icon view for simplicity. The other views will be covered in subsequent months.

Each object is described to the container using a base data type - this can be either the RECORDCORE or the MINIRECORDCORE structure, depending on the CCS_ style used when creating the control. (For the purposes of our discussion, the MINIRECORDCORE structure will be referenced although either could be used.) When objects are allocated, additional memory at the end of the MINIRECORDCORE structure can be requested, for the storage of any object-specific data. Thus, you would have to define a structure to contain both the base data and the additional fields needed: Since the container, when returning pointers to the object records, always returns a PRECORDCORE type, you will need to typecast this to your application-defined type (here, PMYCNRREC).

Inserting and Removing Records
The container makes a distinction between allocation and insertion of records; likewise, a similar distinction is made between removing a record and freeing the memory consumed by the record. Allocation is accomplished by sending the control a CM_ALLOCRECORD message, while insertion is done by sending a CM_INSERTRECORD message.

The CM_ALLOCRECORD requires the number of additional bytes needed in mpParm1 and the number of records to allocate in mpParm2. If more than one record is allocated, a linked list of the records is returned (with the linked being the preccNextRecord field in the MINIRECORDCORE structure); otherwise, a pointer to the record is returned. The container will initialize the entire structure to "nothing" (meaning no icon, no text, etc.). It is your responsibility to "fill-in-the-blanks" so that something meaningful will appear in the control; for the icon view, these fields are the hptrIcon and pszIcon fields of the MINIRECORDCORE structure. You should set them to the handle of the icon and to the pointer to the descriptive text to be displayed, respectively. Using our MYCNRREC structure again as an example: Once you have allocated, initialized, and are ready to insert your records, you need to describe the placement of the records to the container (via the RECORDINSERT structure) to the container. An item of interest is that the container has two notions of order: z-order and item-order. The former should be familiar because PM windows all have this concept. The latter, however, is useful when you wish to enumerate the records in an order other than the z-order placement without affecting the appearance of the records in the container. Continuing our example above: A couple of important things should be noted here:
 * It is very inefficient to allocate and insert records one at a time. If at all possible, allocate many records and insert them all at once.
 * You can specify FALSE for the fInvalidateRecord field to cause the container not to invalidate the records once they are inserted. Doing this allows you to reflow - or arrange - the records in the container before displaying them ( using the CM_ARRANGE) message. If you choose to do this, you must send a CM_INVALIDATERECORD message specifying CMA_REPOSITION and CMA_ERASE to redraw the container.

To remove a record from the list, you use the CM_REMOVERECORD message. If you choose not to have the container free the memory (using the CMA_FREE flag), you must also send a CM_FREERECORD message to return the memory to the system. A "gotcha" here is that the first parameter of the two messages is a pointer to an array of pointers. Thus, if you are only removing one record, you need to specify a pointer to the record pointer:

Arranging the Records
Arranging the records is as simple as sending a CM_ARRANGE message. This message takes no parameters. the record pointer:

Using the CM_SETCNRINFO Message
To change the value any of a multitude of attributes belonging to the container, you can use the CM_SETCNRINFO message. This controls everything about the container including the current view type, which is probably its most widely used feature. The way this message works is that you define a variable of type CNRINFO, set the appropriate fields, and send the message. In the second parameter, you specify one or more flags which tells the container which fields to examine. Thus, you do not have to initialize the entire structure for one field. the record pointer: This provides a very limited example of the CM_SETCNRINFO message. For more information about the CNRINFO structure see the Technical Reference, available with the Programming Toolkit.

Basic Notifications
The container will notify its owner via the WM_CONTROL message whenever any of a multitude of events occur. Five of the more basic notifications are listed: Next month we'll briefly describe a few others and their meanings.

Next Month
Next month, we will look at the tree view as well as look at a few other notifications. Also, we will build our first sample application using the concepts described here and in next month's article.

Example Container Object Record
Used as the object record type throughout this article, the definition is below: