That's a good question.
The answer is, not on Palm OS 2.0 and below. Palm OS 2.0 implements many, many heaps
on a device. Lets say you have a record that is in a heap that has 1K of space left,
and you want to grow it another 2K. But, the rest of the device is empty. If you use
MemHandleResize, it will fail with a memory error. The user will see a memory error,
but also see that there is lots of space left on his Palm, and call you and ask why
your program doesn't work.
That is why DmResizeRecord returns a handle. If you do this:
h = DmQueryRecord (dmRef, 0); // let's assume MemHandleSize (h) == 1
h2 = DmResizeRecord (dmRef, 0, 20000); // grow the record to 20K
Does h == h2? In Palm OS 2.0, sometimes. In Palm OS 3.0, and above, yes, always. My
question is, what about the future?
Note that above, if I instead did this:
MemHandleResize (h, 20000);
It would possibly fail on Palm OS 2.0 because the heap would be full, even if there
was lots of storage RAM left.
Why is this a big deal? There are lots of reasons. You can't easily maintain your own
index of records if the handles change. For speed reasons, you might want to do this.
You can't easily abstract objects that are attached to a database. If the object
grows, the handle changes, and any other copies of that handle become invalid. Anyone
who is trying to create a Palm class library might be concerned about that.
I want to make sure that if I assume future OS's behave the way current shipping OS's
do, my software won't break.
Thanks,
Shannon
>A handle is a method of indirection. Why the concern about
>which heap the actual data is in as long as the handle remains
>the same?
>
>That is to say that the implementation of a handle may change,
>the handle represents nothing but the promise to locate your
>memory when you call for it (with MemHandleLock). MemResizeHandle
>can not now, nor ever, change the handle but it -may- change the location
>of the memory that the handle refers to ... but why would that change be
>of any concern? As long as the -handle- remains unchanged after
>a call to MemHandleResize -- and it will -- shouldn't that be good enough?
>
>-rmh
>
>Shannon wrote in message <5044@palm-dev-forum>...
>
>You are right that MemHandleResize will not change the handle.
>
>In OS 2.0 and earlier, heap sizes were a max of 64K, and could have lots of
>stuff in them. It was often that a MemHandleResize of a database handle
>would fail, requiring it to be re-allocated in another heap. Doing what you
>are describing should work fine in all current post-OS 2.0 implementations,
>but what about the future?
>
>I am considering only supporting OS 3.5 and above with new software, and I
>want to know if I can greatly simplify my memory management schemes in the
>future. One way would be to do as you describe, only using MemHandeResize on
>memory handles.
>
>But, I need a call from Palm to make sure they never go back to a multiple
>heap data architecture. For example, would they consider doing multiple
>heaps in whatever they intend to do with Nokia, or any other OS's they have
>planned? Is this a chip dependent thing? It would be great if we could get a
>commitment to only have one data heap in the OS.
>
>In answer to your last question, DmResizeRecord simply calls MemHandleResize
>in post 2.0 implementations currently. But again, what about the future?
>
>Shannon
>
> >We use handles to create multiple of indices for a database. However we
>always use MemHandleResize. The declaration as par the API docs is
> >
> >Err MemHandleResize (VoidHandle h, ULong newSize)
> >
> >As you can see h is not a pointer to a handle, there is no way the function
>could change the value of h and return it. So, I assumed MemHandleResize
>never changes a handle. Where as DmResizeRecord returns a handle. Chances
>are there, that it will be different than the one I passed. Till now I have
>not faced any problems with this scheme.
> >
> >I understand this restricts us to one heap only. But, this is the best
>index referrence, we could think of. Record positions need to be updated
>constantly, and unique IDs involves a linear search.
> >
> >On a final note, the API docs say
> >"On devices running version 2.0 or earlier of Palm OS � , the
> >MemHandleResize function tries to resize the chunk only within
> >the same heap, whereas DmResizeRecord will look for space in
> >other data heaps if it cannot find enough space in the original heap."
> >
> >So, what happens in devices running version 3.0 or later of Palm OS?
> >
> >-Sugho-
> >
> >>From: Shannon <[EMAIL PROTECTED]>
> >>Reply-To: "Palm Developer Forum" <[EMAIL PROTECTED]>
> >>To: "Palm Developer Forum" <[EMAIL PROTECTED]>
> >>Subject: Can Palm comment on the future of heaps?
> >>Date: Wed, 15 Mar 2000 08:07:33 -0800
> >>
> >>Currently, the API specifies that whenever a storage handle gets resized,
>like through a DmResizeRecord, or a MemHandleResize, the handle might get
>relocated into a different data heap.
> >>
> >>However, since OS 3.0, there has only been one data heap, so that storage
>handles will not get moved when resized. The latest doc makes an offhand
>reference to this in the description of MemHandleResize.
> >>
> >>Can we count on this behavior in the future? In other words, will
>DmResizeRecord ALWAYS return the same handle in future OS's?
> >>
> >>It would be a huge advantage if we could count on non-moving data handles.
>One thing we could do with it is make multiple indexes into a database when
>an application starts up, and be able to count on the handles not changing
>while the application is running.
> >>
> >>Any comment from Palm?
> >>
> >>Shannon
> >>
> >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >>Hands High Software
> >>Award winning software for the Palm(tm) Computing platform
> >>
> >><http://www.handshigh.com/>
> >>
> >>[EMAIL PROTECTED]
> >>
> >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >>--
> >>For information on using the Palm Developer Forums, or to unsubscribe,
>please see http://www.palm.com/devzone/mailinglists.html
> >>
> >
> >______________________________________________________
> >Get Your Private, Free Email at http://www.hotmail.com
> >
> >
> >--
> >For information on using the Palm Developer Forums, or to unsubscribe,
>please see http://www.palm.com/devzone/mailinglists.html
>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>Hands High Software
>Award winning software for the Palm(tm) Computing platform
>
><http://www.handshigh.com/>
>
>[EMAIL PROTECTED]
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
>--
>For information on using the Palm Developer Forums, or to unsubscribe, please see
>http://www.palm.com/devzone/mailinglists.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hands High Software
Award winning software for the Palm(tm) Computing platform
<http://www.handshigh.com/>
[EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
