n my last article, I showed you how to get started with the QUALCOMM BREW UI toolkit and introduced BREW's notion of forms and widgets. In this article, you'll build on that knowledge and look at an entire multi-screen application to see how forms, widgets, models, and listeners fit together.

The IOU application (see Figure 1 and Figure 2) consists of three screens: one to list the money you owe people and money they owe you, and two to let you enter in IOUs and debts owed to you (referred to as "UOMe's" in the source code). It's not a commercial application, but serves two very real purposes: it lets us track our "coffee debts" around the office where I work, and it provided me with a playground in which to work with the BREW UI Toolkit before using what I learn in commercial applications.

Constructing a List of Items
The previous article demonstrated how to set up a simple form and populate it with widgets. Listing 1 shows you how to do this same thing for a form with a menu. However, using the UI Toolkit's support for lists and menus (vertical and horizontal lists are provided, as is a grid list) is a bit trickier.

Figure 1. IOUs and UOMes: This screen lists the money you owe people and money they owe you.

Figure 2. Entering The Debts: This screen shows where you enter in IOUs and UOMes.

Listing 1 follows the same basic structure to create a form as in the first article's example:

• Create a form
• Create a container
• Bind the container to the form
• Create some widgets
• Add the widgets to the container
• Configure the widgets so they appear the way you want

There are a few key differences between initializing a form with static or text widgets and initializing a form with menu widgets.

When configuring the list widget itself, I provide an explicit model for the list widget. This model (created at startup) is responsible for containing the list of items in the list. Listing 1 uses a simplistic data model, keeping each IOU as a name and an amount in a wide character string. More importantly, however, is that the list widget is actually a decorator—a widget that wraps the behavior of another widget, in essence decorating it. In the UI Toolkit, many widgets, such as those providing menus and scrollbars, are actually decorators, that modify the behavior of the widgets they contain through their handling of events and the data stored in their models. The list widget takes another widget (in Listing 1, it's a static text widget), and uses that widget to draw each element of the list given information from the list widget's own data model, the IMenuModel set using IWIDGET_SetModel.

In addition to setting the list widget's data model, you must also configure the height of a list widget's individual item. Do this by obtaining the decorator interface to the list widget, and then setting its item height to the preferred height of the contained widget. Before releasing the decorator interface, set the decorator's widget to be the contained static text widget.

Finally, Listing 1 shows how to intercept events going to a specific widget or to a form. This is essential for large applications, because it lets you keep form-specific event handling in separate methods, which prevents you from cluttering up your event handler. If you're writing in C++, you can think of this as the means by way you provide an event handler method for a specific form class. Listing 1 does this in two ways: it creates a handler for the form containing the list (called the MenuForm), and it also creates a focus listener for the list which will receive notifications whenever the list changes state as a result of user action.