Scott,
Wonderful. I was returning boolean true in response to the form close
event. I guess I should have figured that out given that the formprocs that
worked didn't respond to the close event, so the return was false (I
initialize the retVal to false in the procs). Super.
Regarding the draw order, if I have an init routine that sets all the
handles of field controls, this should take place only after a FrmDrawForm?
Do you always have to draw the form before touching any of the controls?
I'm not doing this in all cases but everything seems to work correctly...
Thanks again, a big help.
Will
-----Original Message-----
From: Scott Johnson [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 16, 1999 12:23 AM
To: [EMAIL PROTECTED]
Subject: Re: Properly handling multiple forms
"Meyer, Will" wrote:
> In some cases, the form that is active does not get erased when I
> "go to" another form.
If you handle frmCloseEvent, be sure to return false from your event
handler. This permits the OS to do its default cleanup where it
erases and deletes the form. If you return true instead, then the OS
will not handle the event to do its cleanup.
> All my forms draw themselves in their init routines
Make sure not to draw anything before the first call to FrmDrawForm in
your frmOpenEvent handler. The first FrmDrawForm is where the
original screen snapshot gets saved so it can be restored later, so
you don't want to vandalize it.
> I'm coming from a Win32 gui background
Welcome, I spent a few years in that barrel myself. :-)
> it seems that the Palm model is more a one-at-a-time approach.
> Is this reasonably accurate?
Yes. The Palm does things that way but the user ends up with an
illusion of the feel of multi tasking. Very clever.
> what do you need to do, if anything, in response to the close event
> as far as the ui manager is concerned?
As I said, just clean up your own stuff and return false so the OS can
clean up the form as a whole.
> Does FrmGotoForm essentially unload the current form and load
> the new one?
FrmGotoForm merely enqueues frmClose, frmLoad, and frmOpen events.
You must handle the latter two events yourself, but apparently you
already do that ok or else nothing would work at all.
> assume there are some rules of thumb regarding when to discard
> and create forms vs. when to switch between them?
For full screen (non dialog) forms, generally you always use
FrmGotoForm to close each form when switching to the next. There's
usually no discernible speed difference, and loaded forms take space
in the (limited) dynamic heap.
(Of course for stacked modal dialogs, all forms in the stack must
remain loaded while they are visible on screen.)
> It seems like it doesn't work when the form contains
> fields to which I have assigned my own text handles.
That's a symptom of the field getting drawn before the initial
FrmDrawForm call in the frmOpen handler.
> but it's not clear what the ui manager does (at least to me).
Get the Palm OS source code... if you can. :-)
-slj-
