Sean,
Thanks for reply. See below.
Gary
===============================================
Gary Gorsline
Easy Business Software
----- Original Message -----
From: "Sean L. Gilley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 11:24 AM
Subject: re: Philosophy - Dialogs VS Forms
>
> > 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??
>
> No necessarily. Honestly, I'm not familier with FrmDoDialog, but a quick
> look at the docs says that it waits for a button tap, then exits. If
> you're only setting a single option, that's okay. What if you want
> to set eight? In one of my programs, I have around eight on/off options.
> Originally, they were each menu items, but that was annoying for the user.
> Now the user can tap a single menu item, and get a form that allow him/her
> to look at the options, see how they are currently set, and change them
> if desired. It's a much better UI this way.
I think that I was wrong about being able to set an event handler for the
FrmDoDialog (spelled incorrectly in my original posting)
Does anybody know for sure whether this can be done - or better yet - why
would you want to do it this way?? Peter Epstein in another post in this
thread thinks you can. { Thanks Peter for your input }!!!
My current preference screen is to set an IP Addr and Port with an accept
button. It works great as a FrmDoDialog and AppStop filters thru just
great.
I am now adding a search screen to the main data entry screen. It talks to
the host to present some data that is scrollable. I originally had just a
data field and a button to lookup that data item which switched back to the
main data entry screen. The FrmDoDialog was just fine for that. I think
that I can not set an event handler for the FrmDoDialog screen, so I believe
I must use a standard FORM for this search screen to handle the scroll
events, search button events and only exit on cancel or select button event
for a specific data record.
Setting an event handler for the FrmDoDialog would be a little (very little)
simpler in that when the FrmDoDialog quit, it would be back at the inline
code where it was called from. But it is very little code to put in the
search form's event handler, code to do that same inline code as with the
FrmDoDialog.
>
> > 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??
>
> Little I've done takes a lot of time, but in the instances I do things
> that take more than a few seconds, I make sure the user has as many cancel
> options as are reasonable up until the processing starts. Sometimes
> that's one chance, sometimes (rarely) it's more. The important thing from
> a UI standpoint is to keep the user informed if things may take a while.
>
Again, Peter has suggested to use progress manager for telling the user what
is up. I have a status field in BOLD that gives over 10 stages of
processing that can occur. The longest stage is about 3 seconds, unless the
connection to the server can not be made, in which it is about 15 seconds.
Modem Power Up is about 8 seconds, but the modem displays it's status while
this is happening. This long code section does have a "are you sure"
question, but no cancel (except the modem power up, which we do handle that
cancel). It sounds like we all agree here.
Thanks again Peter and Sean.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
