Hi there,
I'm trying to sync a custom PC application with the Palm's Datebook. My local table structure is a carbon copy of the Palm Datebook DB , with byte, date and time field types. But I get a " Invalid argument in Datebook" error . I used to get a
"A mapped field went beyond the end of the physical record structure" error, but that was fixed after adding a line of code to pfgPalmSyncWizzard to map ftBytes -> ptByte
My code works flawlessly when trying to sync to the MemoDB, which has just a single string field. I understand that it is most likely a field definition issue, but after reading though the Palm CDK documentation and other sources on the net, I am convinced it is unlikely to be so.
Could it be because I specify a field size for some of my fields ? Please help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't personally ever gotten around to looking at the datebook application, but I suspect you're running afoul of the fact that Palm databasing has no field structure. You've probably just looked at the following definition when trying to set up the field definitions for your table component:
typedef struct {
ApptDateTimeType when;
ApptDBRecordFlags flags; // A flag set for each datum present
char firstField;
UInt8 reserved;
}
This won't actually work, because the "firstField" (and reserved) isn't really a legitimate field - it's a placeholder so that the code can quickly get the address of the start of a set of variable length information for the record. If you look at the DateDB.c file in the SDK, in particular the ApptUnpack method, you'll see that the flags byte contains a set of bit flags that indicate whether different structures such as AlarmInfoType and/or RepeatInfoType are at the end of the record. Since these fields are dependant on bits in the flags field, you can't just set up hard field definitions for them.
This is similar in concept to my Address book example, where the presence or absence of fields depends on the flags field in each record. In the address book, though, all the dynamic fields are always string, so I was able to create dummy definitions for all of them, and have a custom read field event handler that prevented it trying to read in fields that weren't present in the given record being decoded.
You have two options for handling the table:
1) Mimic the address book example and set up field definitions for each field within each defined structure that the record can contain (see ApptUnpack for which structures it can contain and in what order they come in) (and don't include the dummy firstField and reserved fields), and set up a field read event handler that skips over the set of fields for each structure if the flags field says that that structure isn't being included.
2) Set up a custom field and an accompanying field read handler to do the custom work of decoding the raw data into various structures you define that mimic the structures that the Palm records can contain.
I use something similar to point 2 on one of my own projects that use a Palm table - I create a descendant of the Palm table component with public fields that are my additional structures, and a field read/write event handler that takes care of packing/unpacking all the data contained in a dummy custom field from/into the structures. That way, it's all self contained in a single class, and access to the extra data structures within the record are as simple as accessing the appropriate field within the table.
Hope this helps.
Regards,
Paul Gilbert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there,
I'm trying to sync a custom PC application with the Palm's Datebook. My local table structure is a carbon copy of the Palm Datebook DB , with byte, date and time field types. But I get a " Invalid argument in Datebook" error . I used to get a
"A mapped field went beyond the end of the physical record structure" error, but that was fixed after adding a line of code to pfgPalmSyncWizzard to map ftBytes -> ptByte
My code works flawlessly when trying to sync to the MemoDB, which has just a single string field. I understand that it is most likely a field definition issue, but after reading though the Palm CDK documentation and other sources on the net, I am convinced it is unlikely to be so.
Could it be because I specify a field size for some of my fields ? Please help.
I haven't personally ever gotten around to looking at the datebook application, but I suspect you're running afoul of the fact that Palm databasing has no field structure. You've probably just looked at the following definition when trying to set up the field definitions for your table component:
typedef struct {
ApptDateTimeType when;
ApptDBRecordFlags flags; // A flag set for each datum present
char firstField;
UInt8 reserved;
}
This won't actually work, because the "firstField" (and reserved) isn't really a legitimate field - it's a placeholder so that the code can quickly get the address of the start of a set of variable length information for the record. If you look at the DateDB.c file in the SDK, in particular the ApptUnpack method, you'll see that the flags byte contains a set of bit flags that indicate whether different structures such as AlarmInfoType and/or RepeatInfoType are at the end of the record. Since these fields are dependant on bits in the flags field, you can't just set up hard field definitions for them.
This is similar in concept to my Address book example, where the presence or absence of fields depends on the flags field in each record. In the address book, though, all the dynamic fields are always string, so I was able to create dummy definitions for all of them, and have a custom read field event handler that prevented it trying to read in fields that weren't present in the given record being decoded.
You have two options for handling the table:
1) Mimic the address book example and set up field definitions for each field within each defined structure that the record can contain (see ApptUnpack for which structures it can contain and in what order they come in) (and don't include the dummy firstField and reserved fields), and set up a field read event handler that skips over the set of fields for each structure if the flags field says that that structure isn't being included.
2) Set up a custom field and an accompanying field read handler to do the custom work of decoding the raw data into various structures you define that mimic the structures that the Palm records can contain.
I use something similar to point 2 on one of my own projects that use a Palm table - I create a descendant of the Palm table component with public fields that are my additional structures, and a field read/write event handler that takes care of packing/unpacking all the data contained in a dummy custom field from/into the structures. That way, it's all self contained in a single class, and access to the extra data structures within the record are as simple as accessing the appropriate field within the table.
Hope this helps.
Regards,
Paul Gilbert