In developing a UI, philosophies always are a consideration. Lets say your
program has a data entry screen, a menu for preference settings and some "do
it" buttons. The data entry form would allow the event loop to process
events so that the OS handles all field input, popups, scroll bars, etc
(with a little of your own code for these functions).
A menu item for setting a preference is also a form, but could be activated
with FrmDialog. By using FrmDialog, you are essentially causing an inline,
e.g., no event processing considerations necessary (other than UI controls
that require some of your programming, like a scrollbar), program. This is
not a problem, because FrmDialog handles all system events and, especially,
an AppStop by forcing a button press on the dialog form, thus allowing your
app to (hopefully) gracefully exit. I don't see a need here to use an
actual form and the extra considerations for event loop and sequencing of
forms for this type of input. Does everyone agree??
For a "do it" button that processes for a long time, like an function that
interacts with another system via one of the many communications options,
programming this type of function as a long inline code portion disables the
user from canceling the function. Some functions may not be cancelable as
they must complete, others may not be so critical. I have taken the inline
approach on these "do it" buttons as I see much more event sequencing
programming if I broke it up into short sections. What does everyone think
here??
Thanks in advance for your input. Obviously, there are many ways to build a
UI.
Gary Gorsline
Easy Business Software
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
