derricklyh3 wrote:
> I use the code below to create record:
> char* s = MemHandleLock(h);
>
> mes.username = "user01";
> mes.title = "defaultTile";
> //mes.content = s;
> StrCopy(mes.content, s);
For this to compile, mes must be declared somewhat like this:
typedef struct
{
char *username;
char *title;
char *content;
} messageType;
messageType mes;
Is my guess right?
> And the code below for reading record:
>
> mesH = DmQueryRecord(IoADB, 0);
> if (mesH != NULL) {
> messageType *mes = MemHandleLock(mesH);
>
> FrmCustomAlert(1000, mes->content, NULL, NULL);
>
> MemHandleUnlock(mesH);
> }
>
> I can read mes->username and mes->title correctly but not
> mes->content. Would you tell me what is the problem of the
> string read from a field?
The problem with reading the strings from the record is that
the record contains no strings to read! The record just
contains pointers.
Here's an analogy for what you're doing: Let's say you plan
to travel to a plumber's convention and take notes about some
of the new products so that your friend can write an article
about them for a trade magazine. So, you get on an airplane,
go to the convention center, and identify 5 booths where
vendors are showing off their newest kitchen faucets. You
take a piece of paper and write down the booth numbers of
these booths with the kitchen faucets. Then you fly home and
a week later you hand this piece of paper to your friend so
he can write the article.
Then your friend wants to write the article, so he flies back
to the city with the convention center and looks for those
booth numbers. Only now the plumber's convention is over and
there is a cosmetology convention in the same convention center
instead.
For this to work, you've got to write down the actual information
about kitchen faucets on the piece of paper. Unfortunately,
this is harder. It could even require more than one piece of
paper. Writing down booth numbers is easy because you can just
write down one per line. But descriptions of kitchen faucets
might take more than one line, so you need to manage the space
on the paper yourself, defining your own system to understand
where one description stops and the next begins.
Likewise, when writing strings to a PDB record, they will be
of differing lengths. So, you cannot use a struct to do the
formatting work for you, because the sizes of the struct's
fields are fixed at compile-time, and your strings are of
differing lengths. You need to think of the PDB record as just
a sequence of bytes and figure out how you can encode your
data as a sequence of bytes (and how you can decode that
sequence again). One way to encode strings is to put all
the bytes of the string followed by a null terminator into
the PDB record. Then, when reading it out, read character
by character until you find a null terminator. You then know
how long the string is and can do a MemPtrNew() to allocate
space for it. Then you can copy it from the PDB record into
the allocated memory. The next string (or other data item)
can start right after the null terminator in the PDB record.
This makes reading and writing integers a little tricky,
because the processor requires that they are word-aligned.
I sometimes deal with this by reading integers a single byte
at a time, like this:
Int32 i;
UInt8 *pdbbytes = some_position_within_pdb_data;
i = *pdbbytes++;
i <<= 8;
i |= *pdbbytes++;
i <<= 8;
i |= *pdbbytes++;
i <<= 8;
i |= *pdbbytes++;
Reading strings is much easier:
Char *newstring;
UInt8 *pdbbytes = some_position_within_pdb_data;
Int32 len;
len = 1 + StrLen ((Char *) pdbbytes);
newstring = MemPtrNew (len);
if (newstring != NULL)
{
StrCopy (newstring, (Char *) pdbbytes));
}
pdbbytes += len;
Writing to the PDB is a tad bit more tedious...
Hope that helps.
- Logan
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
