Thanks everyone for the quick responses - I should have been clearer.
Take the MemoPad tutorial. As you mention, it gives the record handle
to a text field control.
However, from tracing the code inside the control it does not appear to
call DmWrite. It appears that the memory is manipulated using the
memory manager. This makes sense, based upon the SDK documentation on
memory management and the ability of the control to take Handles from
any heap.
FWIW, I understand the 'why' of DmWrite - If an app trashes the heap, oh
well. Only one app runs at a time and you can cleanup. Having an app
trash the user's data is an entirely different matter.
I don't want to trash data, but I do want to do some things:
1. Improve performance.
Example, I do modified dictionary type compression (ala, LZxx, zlib,
zip, etc.) Anyone who has tried to do this on palm probably can tell
you that the hash table/dictionary pushes memory limits. When we added
network support I had to stick my dictionary in Dm space. I take a huge
hit in calls to DmWrite to update the dictionary (I do write a whole
entry in one call, but I don't cache any deeper since it would make
indexing and hashing too hairy). The speed is still acceptable, but if
I could reclaim some cycles, I could do a more aggressive compression -
which everyone wants for wireless ($0.20 a K on Palm VII<grin>).
2. Write 'friendly' functions with less hassle.
I don't do most of our palm stuff. I typically write bits and pieces
(ex. compression, graphical data rendering, signal analysis, etc.) I
like those pieces to be as generic as possible - fewer headaches for the
other developers. Using the same example, instead of having a
CompressToRecord and a CompressToHandle, etc. I just have a Compress.
Currently, Compress checks which heap the destination handle is from and
then uses one of two different writing methods - one optimized for
DmWrite and one that uses direct memory access. This is friendly for
the caller, but it is kind of a headache to write. It is also a QA
problem. When I pass the module on to someone to test, they may not
realize that the same code is not getting exercised depending upon how
the memory is allocated.
If I could use one safe write routine, my code would be smaller and
easier to test. This happens a lot in the OS, so I figured it might be
handled at the Memory Manager level.
3. Avoid leaks
Currently, I am creating a Database to use Dm Memory instead of just
calling DmNewHandle. It's kind of a hassle, since some of my modules
end up mucking with SysCurAppDatabase, DmDatabaseInfo, etc. to get a
creator ID, but I've always been afraid of DmNewHandle. The
documentation urges you to attach the handle to a database ASAP, lest
the block be orphaned in the event of a crash. With a database, the
memory gets reclaimed the next time the app is run, the next hotsync, or
when the app is deleted from memory.
I figured if I understood how portions of the OS treat Dm and dynamic
heap records interchangeably and safely I'd be more certain that I'm
using Dm space safely in our apps.
Last note, I did a quick grep of all the Palm samples we have on our
network and "MemSemaphore" does score some hits. I don't know if those
originated with Palm or if they are from other sources. I'll look at
the files tomorrow or Friday.
Thanks again to everyone for the quick response! Sorry about the long
post, but I wanted to make my goals a little clearer with specific
examples.
Best Regards,
-jjf
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 02, 2000 7:36 PM
To: Palm Developer Forum
Subject: Re: DmWrite Question
> Some of the SDK examples and the MemoPad tutorial edit a record
> directly. I've traced it a bit and DmWrite seems to be bypassed. It
> appears to me that the record handle is just being manipulated
directly
> using the memory manager.
Could you post the examples that appear to contradict your
understanding?
Perhaps there's something specific there that we can explain to you.
For
instance, most of the data in MemoPad is manipulated with Field Manager
calls
(like FldInsert), which call DmWrite for you.
But in general, yes, DmWrite is required when modifying data in the
storage
heap, and no, you should not try to end-run it.
-- Keith Rollin
-- Palm OS Emulator engineer
--
For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palm.com/devzone/mailinglists.html
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
