|
|
|
|
|
|
|
|
Hello World! (continued)
Beginning at the beginning - or just a tad before
Now, let's see how these routines fit together as a few events occur. We won't go through all the events; there's many events we don't need to handle. The OS does their default handling. These events march through the event handlers and each handler returns "no, I didn't handle it."
Program launch; display the main form
Something starts our program. There are various "launch codes" that indicate how or why a program has started, but for now we'll assume a standard program start by tapping the icon in the application launcher.
We'll ignore all the set-up stuff that happens before our code. Just accept that some magic happens and the application begins running. We can cover all the gritty details another time.
Palm OS passes PilotMain() several parameters. The first is the launch code. For now, we'll ignore the other parameters; HELLO.PRC doesn't use them.
Gotcha! #1: Check the launch code before using static or global data!
Applications may run under special conditions when static and global data are not accessible. Attempting to use this data will crash the PalmPilot!
For example, let's assume you (erroneously) initialize some data prior to checking the launch code. When the user does a "find", your program will be called with a sysAppLaunchCmdFind launch code. During this launch code, your static data is not available. Remember the magic happening before your app launches? Making your data available is part of it. And it doesn't happen for the "find" launch code!
Your application starts, attempts to initialize the data, but the data isn't accessible! Boom! Your application crashes, displaying "fatal error."
|
If it is a sysAppLaunchCmdNormalLaunch, then PilotMain() calls StartApplication() to do initialization, then enters the event loop in EventLoop().
Inside the event loop
The event loop gets the next event: it's a frmLoadEvent. This event is a result of the call to FrmGotoForm() in StartApplication().
The event loop passes the event to SysHandleEvent() then to MenuHandleEvent() then to ApplicationHandleEvent(). Here, we initialize and activate the form, and tell Palm OS the form's event handler. When ApplicationHandleEvent() returns, the event loop gets the next event as this one's now been handled.
The next event is frmOpenEvent. This marches through the event handlers (each returning "not handled") until it's passed to FrmDispatchEvent(). FrmDispatchEvent() sends it to the active form's event handler, which is our MainFormHandleEvent(). MainFormHandleEvent() handles it, displaying the form and controls as described before. It returns "handled" so the event loop asks for the next event.
This time there isn't any, so the OS sits and waits. Eventually, the user presses the "hello again" button, so the OS puts a "button pressed" event (i.e., ctlSelectEvent) into our queue. As our application is waiting for an event, its immediately passed on to the event loop. Actually, we've gotten a whole slew of events as the user presses the button. These events went through each handler - each returning "not handled" - so Palm OS handled them. These are events like "pen touched the screen" (penDownEvent), "pen lifted off the screen" (penUpEvent) and so forth. Palm OS recognizes these relate to the button control on our form, so there are other events related to the button, the final one being the ctlSelectEvent which we use to trigger our work.
|
|
|
|
|
|
|
|
|
|
|
