Forgive my newbieness. Please use small words when replying. ;-)
[EMAIL PROTECTED] wrote:
>
>Programs should never request functionality without designing to make sure
>that there is enough memory for success. Or at least that is the followed
>approach.
In other words, if you're gonna use it, make sure it's available? I do
this with pointers certainly. My original question was, should I have to
do this for resources, a form in this case, and if so, how. Are you saying
that I should check for memory required to load a form, for example, before
loading the form?
>In general,
>optional UI services that the user can request like the keyboard, find
>dialog, the old launcher, and so on were designed to fail gracefully when
>there isn't enough memory. It's not ideal because the user's request is
>being denied, but it's safer.
This I understand. Makes perfect sense to me.
>Non optional requests like opening a
>database or displaying a form are designed to fail when there isn't enough
>memory. These are cases were the program design must account for
>sufficient memory. The belief is that the code is smaller and simpler when
>it doesn't have to detect and recover from this problems, and that's it's
>not unreasonably hard to do.
Again, I think I understand the rationale for this. In other words, it's
my code's responsibility to make sure that there's sufficient memory for
"non-optional requests". What's not clear to me is if I should do this by:
1) Ensuring that my code is always leaving sufficient headroom for "non
optional requests", that unspecific number you refer to
or,
2) Checking that there is sufficient memory for something like
FrmInitForm() *before* calling the function.
>As proof, we followed this for all of our
>apps.
I hate to be obtuse, but can you point me to an example of this? Looking
through the code, no technique or process jumps out at me. I'm certain
this is because I'm having a conceptual problem about how you "followed this".
>But there are some simple techniques. Generally, go to the deepest part of
>your UI, and then pop up system dialogs (keyboard or find or contrast or
>whatever). Try and have a low battery alert or alarm then happen.
>Ideally, check how much heap is left. Alternatively, develope with an
>extra buffer (a few KB) which you can remove for the release build. This
>will flush out problems and assure you of a minimum buffer for your users.
How many extra K is "a few"? ;-)
I know there's probably no straightforward answer to this, but without
somewhere to start, as a newbie, I'm lost.
>To test, run gremlins until the device fills, then keep on
>going for a while longer. Alternatively, allocate memory until the storage
>heap is full, then test. There is the console 'hf 1 400' command for those
>with PalmDebugger or Simulators so you don't have to do this
>programatically.
You know, I'd love to see some documentation on the debugging console.
I've read the two page command summary, read all the help for those
commands, scoured the manual called "CodeWarrior Debugger" and I can't find
word one on really understanding the console. Perhaps I've missed something.
The command:
hf 1 400
I interpret as HeapFill heap 1 and leave 400 bytes free. Running this
command on the debugger (CWR5 with patch installed, POSE 2.1d26 and the
Palm III debug ROM) yields the following error under all conditions, even
when my application isn't loaded:
"Date Book 3 has failed. Date Book 3 reports "MemoryMgrNew.c, Line 1341,
Invalid heapID". If this is the latest version of Date Book, please report
this to the application author."
I'm going to post to a different thread some questions regarding the
console and how to use it.
>As for FrmInitForm, since it's the most common function to fail when apps
>are too low on memory, an error was added last year to better indicate the
>problem ("Out of memory").
Read the OS code, the docs and the 3.1 API. I can't find the error to
which you refer. Was this post 3.1 and that's why I can't find it?
Thanks for your patience. I really appreciate the time people take to
reply to those of us who are new at this. Hopefully, you're building
better programmers in doing so.
Cheers,
--
Andrew Ball
[EMAIL PROTECTED]
