Well, that depends on the type of control. For a button, we get a ctlSelectEvent event when the user taps and releases the button. We saw in the "hello world" application how a button works: it's drawn when the form is drawn, and when the user presses it, the ctlSelectEvent message triggered the application to do some function. Listing B (at http://www.component-net.com/pp-extras/control2.html) shows that section of the form event handler. For the full program, see the May 1998 issue.

Repeating buttons use a similar event, the ctlRepeatEvent. One thing to remember: the ctlRepeatEvent handler needs to return "not handled" so the event will be passed on to the handler within the OS. If you don't, the button won't repeat. Normally, the section in the form handler which deals with the control's selection returns "handled", since it did do something with that event.

The controls generate several other events; we can act on these events if we want to do something special. The ctlEnterEvent indicates that the user has tapped on a control; at this point the pen is still down. The ctlExitEvent indicates the pen was dragged outside of the control. If it's dragged back into the control, there will be another ctlEnterEvent. These allow activity to occur when a user presses on a control, rather than upon the release.

Sometimes I prefer to let the OS track the control's settings and then get the value when I close a form. I do this in my application's preferences screen. The user can select his or her preferences, and rather than acting on each ctlSelectEvent, I wait for the form to exit, and then query the OS for the current state of each control. Naturally, this doesn't work for buttons. They're only "set" as long as the user is pressing on them. But it works fine for pushbuttons and checkboxes. It has the added advantage of delaying any real changes until the form exits, so I can implement a Cancel button on the form. This way, when the user presses the Ok button, the exiting-form routine gets the value of each control and remembers whatever information it should. If the user presses Cancel the form just exits without updating getting any control settings or changing any of the application's information.

Next month
We'll keep digging into controls as time goes on, and we'll get into other UI objects, especially fields; they tend to not work as you'd expect. But I think next month we'll start playing with some more code. My 3-year-old son's been clamoring to play with my PalmPilot, so why don't we write a simple game? Let's seeÉ some bitmaps, some pen-tap recognitionÉ

Until then, keep all your bits where they belong!

Alan Weiner fiddles with bits and dabbles with data. His email address is alan@ajw.com.