By Alan Jay Weiner
Since this is my first column for 1999, let me start by saying Happy New Year to all of you. I'd also like to thank PalmPower readers and staff for letting my take January off and get some sorely needed "rest and recovery" (which looked an awful lot like catching up on some other work...).
[Shhh... Alan, don't let it get out that we let our writers off the hook. It'll be bad for my reputation as a tough, unrelenting, merciless, Editor-in-Chief. -- DG]
In any case, back to work...
Almost any application that uses text entry will use fields. Fields are the standard Palm OS user-interface element for text entry. The system knows how to handle attributes such as automatically capitalizing the first letter, word-wrapping, expanding to multiple lines and so forth. Certainly that's easier than writing our own text-entry routines -- especially if you need multiple lines with word-wrapping!
Shown in Figure A, this month's sample program, Infield, provides some basics of field usage, along with a couple of special functions: only allowing digits and forcing text to upper case. As usual, it's based on the original "Hello, world" program, so most of it will be familiar.
FIGURE A
Infield is a simple little program that shows off field operations.
Fields are complex little beasts
First, let's look at how the field itself works. You define fields along with forms in whichever tool you use to build the resources -- Constructor if you're using the Metrowerks compiler, or PilRC if you're using the GCC tools.
Fields have many attributes, including the typical positioning information (upper-left corner's X and Y coordinates, and the width and height), and usability (enabled or not). They also have names and ID numbers like any other Palm OS user interface (UI) element.
Beyond these attributes, the field can be underlined or not, limited to a single line, editable or not, numeric only. Other attributes include wild-and-wooly things like dynamic sizing and scroll bars. To really cover fields entirely will take many, many columns; they don't always work as you'd expect. For this column we'll just stay with some basics and a couple of tricks to keep things interesting.
The simple stuff
Most of the field activity is handled by the default form handler. When your EventLoop function calls FrmDispatchEvent, the event goes to the form handler you've set. If your form handler doesn't handle the event, it then goes on to the default handler. Usually your form handler doesn't do anything special with field events. The default handler does all the right stuff, given the attributes you've defined for the field. At least, it mostly does -- there are times where things don't work as you think they should. We'll look at some of those later on.
