Peter, thanks for the comments.
I do handle the window update event, even though there is no "target PalmOS
style" window in my system, I handle all generated events. Since it is up to
the programmer to apply the event to the appropriate window anyhow, I apply any
update events to my "current" window. That all works fine.
I wrappered by entire program with:
case sysAppLaunchCmdNormalLaunch:
FormType* form = FrmNewForm(1, NULL, 0, 0, 160, 160, false, 0, 0, 0);
FrmSetActiveForm(form);
/* rest of program */
FrmDeleteForm(form);
Now system dialogs don't complain. It seems a waste of 76 bytes of memory, but
I guess in hindsight since the system dialogs are using the system window
manager, it needed to be initialized.
What is the right way to initialize the window manager so system dialogs will
work properly without creating a dummy form? FrmSetActiveForm was the key to
making this work, just initializing a form didn't do it.
Peter Epstein wrote:
> I'm afraid you've got a real problem here. When dynamic memory is low, the
> OS will fail to save the bits under dialogs. In this case, when the dialog
> is closed, it'll try to redraw the affected areas using update events. This
> will fail if you don't have a window to update. I'd consider just creating a
> blank form and handling the update event appropriately.
> --
> Peter Epstein
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
