>> This is intentional. In low memory situations, dialogs
>sometimes can't
>> allocated enough memory to store the portion of the screen they're
>> drawn on top of. In this case, when the dialog is dismissed, the form
>> has to do its own redrawing. The debug ROMs simulate this low memory
>> condition to expose latent bugs in applications. In order to get your
>> application to refresh properly on the debug ROMs (and on
>release ROMs
>> when memory is low), all you need to do is to handle the
>> frmUpdateEvent, and make it call FrmDrawForm, followed by any WinDraw
>> lines and such, then return with handled = true. -- Peter
>Epstein Palm
>> Inc. Developer
>
>That is what another person said but here is the problem.
That would be me.
>Here is the situation. Say you have an application that offers the
>users the ability to program, within the application. I mean an
>application that allows the user to say write a program (within the
>application) that will graph to the screen. In addition to the user
>program that can draw, which is completely unknown to the
>FrmUpdateForm event, you now require the application to keep track of
>the user's program steps again. You have to do this because you
>never know when a popup will come up over this graphing. So, to be
>able to refresh you have to keep track of all graphing steps that
>were performed.
>
>How does anyone overcome this limitation in this case?
>
That's why you have virtual events. Since you HAVE to be able to handle
any event (that's what event handlers are all about)at any time, including
nilEvents, you then add an event into the queue in cases like this.
Whatever concievable action the user could take should be handled,
one way or another, in your event queue. If it isn't concievable, you
let your default handler take care of it (usually by ignoring it). All
the FrmUpdateForm event does is pump an updateEvent into the event queue.
You can also write your own psudo-system Event Handler that catches a
particular event before the system gets its paws on it, by placing it
ahead of the SysHandleEvent and the rest in the event queue (I do this
with catching key presses all the time).
In short, whatever the user does will generate some kind of event. If
you design your event handler correctly and robustly, you should be able
to let your system react to any event like this.
//* Rus Daniel Nesse
//* Application Development
//* Avnet Convergent Technologies
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
