"Richard Hartman" <[EMAIL PROTECTED]> wrote in message
news:5627@palm-dev-forum...
> That's too bad ... I am having similar symptoms
> (that were cleared up by checking "save behind",
> thanks for that!).

Make sure you test your app with a Palm OS 3.5 debug ROM. The debug ROM
"fails" to save behind, because that's exactly what happens when the device
is running out of memory. If it looks wrong on the debug ROM but works on
the release ROM, it's an indication that you're not correctly handling the
frmUpdateEvent. There was a discussion on this forum about exactly what to
do when you get this event. If I recall correctly, you should make it call
FrmDrawForm, do any other drawing that is needed, and return true (so
nothing else tries to handle it). I think it used to be possible to just do
any other drawing that is needed and return false, but that no longer works.

> Question 1: why would one want (or not want)
> "save behind" checked?  It seems that the default
> for constructor is not checked, but that is the mode
> that causes these symptoms.

Common practice is to turn it on for dialogs, but with a color display, the
memory consumed is much greater, so dealing with the possibility that it may
fail is more important than ever.

> Question 2: I don't -think- my code is calling FrmGotoForm
> more than once the way Bradly's was ... so what else
> could be going on that would cause these symptoms?

I ran into problems like this when porting a game to 3.5. I don't have
specific advice, but I found it pretty easy to track down the problems by
stepping through the code in the debugger. I stepped over a statement that I
didn't expect to do anything on the screen, but it did. Older versions of
the OS were more forgiving about how a form is initialized and drawn, and it
appears that many of us weren't doing things 100% by-the-book.



-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palm.com/devzone/mailinglists.html

Reply via email to