This doesn't really address the problem mentioned, but does concern the
general idea of 'packing' a record...
Anyone using the code from O'Reilly should beware of a potentially nasty
but easy to fix 'buglet' in the style of the routine for 'packing' data
into a record. They define 'Customer' and 'PackedCustomer' as (for example):
typedef struct
{
SDWord customerID;
char name[1];
} PackedCustomer;
typedef struct
{
SDWord customerID;
const char *name;
...more text fields here
} Customer;
The 'pack routine adds up the sizes of all the elements of the unpacked
struct and allocates memory for the packed record. This is all well and
good the way it's written and for the example they give it happens to work,
but let's say you had
typedef struct
{
Byte n;
UInt i;
char text[1];
} PackedStruct
and the corresponding struct for the unpacked form. Following the book,
you'd get some really messed up results if you unpacked the data you just
packed. I spent FOREVER trying to figure out what was mangling my data
until I remembered that Motorola processors do things Word-aligned. That
means for the above struct, it is actually one byte BIGGER than you'd
calculate just adding the 'sizeof's of each element. A pad byte is stuck
between the Byte and UInt above. Grr.
What I do when I need to know the amount of memory to allocate for a packed
struct is something like
memneeded = (sizeof(PackedStruct) - 1) + StrLen(str1) + StrLen(str2) + ...
+ numstrings;
The -1 takes off the size of the single char placeholder at the end of the
struct, and numstrings accounts for null terminators on each string.
The rest of the function is basically the same as the book's.
If the book actually mentions this caveat and I missed it, please accept my
apologies. I just don't want anyone else to go through the nightmare
debugging that I did for such a little thing. Packing records is a very
GOOD THING to do, though.
Kris Wilk
ReefNet Software
www.reefnet.on.ca
At 12:50 PM 2/14/00 , you wrote:
>I'm trying to save data from several forms onto one record. I have set up a
>struct to organize the data. It contains an array of characters of length 1
>(this idea from O'Reilly's Palm Programming book) and a few other types.
>This approach works fine as long as all the "other types" are written before
>I write the string. On the other hand, if I try to write an int (for
>example) after having written even part of the string, the string gets
>destroyed. I'm pretty sure this is happening because the offset to some of
>the other types lands right on the text, which is officially only allocated
>1 character. Therefore, an alternative would be to allocate a number of
>characters big enough to fit the string to the array, but I'd like to be
>more efficient with my space.
> The problem arises when I try to append information to the record as I try
>to save data from a second form, so I have to write both text and numeric
>data to a record that already contains both. I could recreate the whole
>record, but that's not very efficient with regard to performance.
>
> Can anyone with more experience offer any ideas to get around this
>problem? Any literature that might help?
>
>Thanks in advance.
>Luca
>
>
>--
>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
