Hi Ted. > What is the proper way to find the storage heap on a particular card? > ie, differentiate the storage heap from the dynamic heap and the rom > heaps?
I think John Gruenenfelder is right. You said the ROM storage heap was first. I thought it was last. I thought you could enumerate the RAM heaps by going from heap number 0 to heap number MemNumRamHeaps() - 1. This assumes RAM heaps are first. But Keith is right to avoid pre-flighting, even in a controlled environment. My own experience backs this up. The problem is that you can't predict how fragmentation will affect your ability to allocate chunks. If you use *maxP passed back from MemHeapFreeBytes, you won't have to worry about fragmentation. But this is likely to indicate that your allocations will fail, when in fact they'd succeed. If, on the other hand, you use *freeP, you're assuming that fragmentation won't affect you at all. Two other points to consider: 1. How do you know how much space you need to allocate? When you call DmNewRecord, for example, the Data Manager has some overhead beyond the actual record size. The Memory Manager has additional overhead. This overhead can be computed, but it varies with OS version. So even if fragmentation wasn't an issue, you could only predict your memory consumption if you knew which OS you were running on. This is only a problem if you're allocating lots of little chunks. 2. What if an alarm goes off or some other sublaunch occurs while you're receiving data? If you're calling SysHandleEvent (or PrgHandleEvent), this can happen. So if you don't pre-flight, what do you do? One option is to pre-allocate a big chunk and then hand out pieces as you need them. This is tricky because the Data Manager and Memory Manager don't have APIs for splitting chunks up. But if you resize the large chunk smaller, you should then be able to allocate the freed area at the end. But a fragmented heap will prevent you from allocating the initial large chunk, even though there is plenty of room for the individual pieces you actually plan to allocate. You can start with a bunch of smaller chunks, but you're really just implementing your own memory manager. :) Another option is to handle allocation failure at any point. To do this well requires exceptions, something that is only minimally supported in Palm OS. See Ken Krugler's article if you want to consider this approach: http://www.unna.org/unna/development/documentation/HandheldSystemsArchive/ar ticles/1998/6.4/10krugle.pdf http://oasis.palm.com/dev/kb/papers/1909.cfm You'll need to do a lot of testing to make sure you handle running out of memory everywhere you do allocations. This can be done by pre-filling memory and then letting Gremlins loose on your app. There are no easy answers. :) - Danny -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
