Handling Categories
The Generic Conduit Framework handles
categories
oddly—it expects that the category data will be stored on the
desktop in the same way it is stored in the
AppInfo
block. Most applications won’t use
this strategy, but instead will probably choose to store categories
by saving the following:
The category name
The category ID (a number from 0 to 255, where 128 and above are reserved for categories created on the desktop)
A dirty bit (showing that the category has been edited on the desktop since the last sync)
To begin with, you’ll need to notify the Generic Conduit
Framework that you’ll be using categories. You can do this in
OpenConduit
(see Example 16-5) by changing the last parameter in
the constructor from the 0 value that signifies that you don’t
use categories.
ExportFunc long OpenConduit(PROGRESSFN pFn, CSyncProperties& rProps)
{
long retval = -1;
if (pFn)
{
CMemopadConduitWithCategoriesSync* pGeneric;
pGeneric = new CMemopadConduitWithCategoriesSync(rProps,
GENERIC_FLAG_CATEGORY_SUPPORTED| GENERIC_FLAG_APPINFO_SUPPORTED);
if (pGeneric){
retval = pGeneric->Perform( );
delete pGeneric;
}
}
return(retval);
}
In order to deal with categories, you’ll need to write out the
category ID of each record when you write out your file. In addition,
you’ll need to write out the categories themselves. Example 16-6 shows a modified StoreDB
,
with emphasized lines showing the changes that were necessary for
categories.
Get Palm OS Programming, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.