Palm OS Web Application Developer's Guide: Developing and Delivering PQAs with Web Clipping

After the request has been sent to the server, the program can return to its event loop. Because we are now using the event-driven model, INetLib signals us with events after the data is ready. Even intermediate status messages arrive as events.
After you have modified the event loop as specified in the earlier section Moving to an Event-Driven Model, you do not need to worry about INetLib events. You will get informed if and when any change occurs in the status of INetLib. However, you still need to verify that your event handlers handle the two INetLib events. If you allow the user to switch forms while the transaction is in progress, you must make sure that INetLib events are always handled. You can either require the handler code to be called directly from EventLoop or make the event handlers of each of the forms handle the events appropriately. If you are displaying status messages while handling INetLib events, make sure that they do not try to access form objects that do not exist. The code shown in Figure 11.5 is taken from the UWMail example (discussed later in this chapter).
/* code snippet - variables are declared elsewhere */case inetSockStatusChangeEvent:case inetSockReadyEvent: handled = HandleINetEvents(event); break;/* code snippet */Boolean HandleINetEvents(EventPtr event){ Boolean handled = false; INetEventType *ievent = (INetEventType *) event; if (event->eType == inetSockStatusChangeEvent) ...